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

[Avi Kivity]

Ian Jackson wrote:
> Avi Kivity writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle 
> terminating signals."):
>   
> > Ian Jackson wrote:
> >     
> > > 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.
> >     
>
> That doesn't make us any less exposed to bugs in the threading
> implementation, and is only of marginal use if anything for explaining
> to people why we shouldn't have a Windows-style multithreaded bug
> pile.
>
>   

Threading bugs in the implementation?  In 2008?

Practically all serious software is multithreaded nowadays.

> Also, I think messing about with Linux-specific syscalls and then
> emulating them is hardly a sensible way to carry on, when the
> alternative is portable and simple.

This has merit; though signalfd() will be a lot faster than catching a 
signal and writing to a pipe.

In particular, delivering a signal to userspace has to save the floating 
point context, while signalfd() avoids it.  With the signals used to 
signal I/O completion, this matters.

--
error compiling committee.c: too many arguments to function