Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals.

[Avi Kivity <avi@xxxxxxxxxxxx>]

Ian Jackson wrote:
> Avi Kivity writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle 
> terminating signals."):
>   
> > Not sure that it matters, but the semantics are slightly different:  
> > with a thread you don't get EINTR in random syscalls as the signal 
> > thread is the only one that has the signals unblocked.
> >     
> That's true but I don't think it's really relevant because we already
> have other signal handlers (and we might grow further ones) so the
> rest of the code has to be robust against those.
>
> My experience suggests very strongly that we should avoid doing
> multithreaded things if at all possible.  Threads are less portable;
> even when they are provided many of the implementations are buggy
> (although less so nowadays).
>
> There is also the way that once you have a multithreaded program, it
> is much more difficult to discourage the expansion of the concurrent
> functionality until the whole program is a mass of race bugs.  I would
> rather not open this stable door.
>
>   
In this case the thread is only used to emulate the signalfd() system 
call; it is not part of qemu proper.
--
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel