9:58 a.m.
On Mon, Mar 26, 2007 at 03:39:51PM +0100, Richard W.M. Jones wrote:
I'm not sure if this is the right way to solve this, but it is a
way.
we should test the return value to check for an error there, the
unfortunate thing is that since we are in a signal handler there isn't
much we can do, I suggest to increment a global variable (which could
for example be checked if we hit that problem by some other code in
the main loop).
Other ideas ?
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
10:22 a.m.
Daniel Veillard wrote:
On Mon, Mar 26, 2007 at 03:39:51PM +0100, Richard W.M. Jones wrote:
> I'm not sure if this is the right way to solve this, but it is a way.
we should test the return value to check for an error there, the
unfortunate thing is that since we are in a signal handler there isn't
much we can do, I suggest to increment a global variable (which could
for example be checked if we hit that problem by some other code in
the main loop).
Other ideas ?
How about this patch. It implements your suggestion.
Rich.
10:25 a.m.
On Mon, Mar 26, 2007 at 04:22:33PM +0100, Richard W.M. Jones wrote:
Daniel Veillard wrote:
>On Mon, Mar 26, 2007 at 03:39:51PM +0100, Richard W.M. Jones wrote:
>>I'm not sure if this is the right way to solve this, but it is a way.
>
> we should test the return value to check for an error there, the
>unfortunate thing is that since we are in a signal handler there isn't
>much we can do, I suggest to increment a global variable (which could
>for example be checked if we hit that problem by some other code in
>the main loop).
> Other ideas ?
How about this patch. It implements your suggestion.
Looks good to me.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
10:39 a.m.
On Mon, Mar 26, 2007 at 04:22:33PM +0100, Richard W.M. Jones wrote:
Daniel Veillard wrote:
>On Mon, Mar 26, 2007 at 03:39:51PM +0100, Richard W.M. Jones wrote:
>>I'm not sure if this is the right way to solve this, but it is a way.
>
> we should test the return value to check for an error there, the
>unfortunate thing is that since we are in a signal handler there isn't
>much we can do, I suggest to increment a global variable (which could
>for example be checked if we hit that problem by some other code in
>the main loop).
> Other ideas ?
How about this patch. It implements your suggestion.
yup, better than I would have done myself (didn't knew there was
a specific type sig_atomic_t for atomic access...).
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
5:30 a.m.
Daniel Veillard wrote:
On Mon, Mar 26, 2007 at 04:22:33PM +0100, Richard W.M. Jones wrote:
> Daniel Veillard wrote:
>> On Mon, Mar 26, 2007 at 03:39:51PM +0100, Richard W.M. Jones wrote:
>>> I'm not sure if this is the right way to solve this, but it is a way.
>> we should test the return value to check for an error there, the
>> unfortunate thing is that since we are in a signal handler there isn't
>> much we can do, I suggest to increment a global variable (which could
>> for example be checked if we hit that problem by some other code in
>> the main loop).
>> Other ideas ?
> How about this patch. It implements your suggestion.
yup, better than I would have done myself (didn't knew there was
a specific type sig_atomic_t for atomic access...).
Committed to CVS.
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
"[Negative numbers] darken the very whole doctrines of the equations
and make dark of the things which are in their nature excessively
obvious and simple" (Francis Maseres FRS, mathematician, 1759)
6485
days inactive
6486
days old
5 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones