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

[Anthony Liguori <anthony@codemonkey.ws>]

Avi Kivity wrote:
> 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())

That's a really good idea.  I'll update the patch.

Regards,

Anthony Liguori


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