Re: [PATCH] Use pipe() to simulate signalfd() (v2)

[Avi Kivity <avi@qumranet.com>]

Anthony Liguori wrote:
>> We can keep the signals blocked, but run the signalfd emulation in a 
>> separate thread (where it can dequeue signals using sigwait as an 
>> added bonus).  This will reduce the differences between the two modes 
>> at the expense of increased signalfd() emulation complexity, which I 
>> think is a good tradeoff.
>>   
>
> signalfd() can't be emulated transparently with a separate thread 
> because you won't be able to wait on signals destined for the specific 
> thread (only signals sent to the process).  We deliver signals 
> directly to the IO thread (specifically, SIGUSR1) so this could get 
> nasty.  We could just not block SIGUSR1 and rely on the fact that it 
> will break us out of select() but I that makes things a bit more 
> subtle than I'd like.
>

We can completely kill off SIGUSR1 and replace it with its own pipe.  
There's hardly any point in asking the kernel to signal a task, then 
having the kernel convert this to a fd write.

(Or maybe use eventfd())

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


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone