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

[Anthony Liguori <anthony@codemonkey.ws>]

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.
>