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

[Anthony Liguori <anthony@xxxxxxxxxxxxx>]

Ian Jackson wrote:
> Anthony Liguori writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle 
> terminating signals."):
>   
> > Then you need a pipe per-signal and you can't accurately simulate 
> > threadfd() (since you can't communicate siginfo).
> >     
> No, you don't need a pipe per signal.  You only need multiple pipes if
> you have multiple different event loops which are each capable of
> handling only a subset of the signals, _and_ you're unwilling to use
> an atomic flag variable (eg, cpu_interrupt) or its equivalent.
>
> But we already have cpu_interrupt, and of course the aio completion
> system has its own recording of what's going on.  So that does not
> apply to qemu.
>
> All that's needed is a reliable, race-free, way of avoiding spuriously
> blocking in a syscall when an event occurs between checking the state
> variables (aio_error, cpu interrupt check) and the call to select().
> One fd is sufficient for that.
>
> Just to make that concrete, even if we extended my patch to use its
> mechanism for SIGINT et al I don't think a second pipe would be
> needed.
>   
In KVM, we do use the signal number to determine action.  We could use 
globals but since we're multi-threaded, that gets pretty nasty.  The 
same would apply to a threaded QEMU.
> > I don't see threads as a problem.  Are you concerned about mini-OS?
> >     
> Minios certainly doesn't currently have any threads and it would
> probably be a severe pain to introduce them.  That's just one example
> of a portability problem.
>   
We're definitely not going to avoid threads forever in QEMU.  KVM 
requires threads to support multiple VCPUs.  Threads are also needed to 
support true SMP with TCG.
And right now, implementing a thread pool is the only sane way to get 
reasonable disk IO in userspace.
I share your concerns about threading, which is why we have to use them 
in a very careful way.  My signalfd() patch uses them in a very isolated 
way that is pretty easily verified.
You could always add proper signalfd() support to minios.  You can also 
certainly implement a signalfd() emulation that uses pipe().  signalfd() 
is really the right solution to this problem (and it doesn't require 
threads by default).
Regards,

Anthony Liguori

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