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

[Anthony Liguori <aliguori@us.ibm.com>]

Marcelo Tosatti wrote:
>>> Moving the signal handling + pipe write to a separate thread should get
>>> rid of it.
>>>  
>>>       
>> Yeah, but then you just introduce buffering problems since if you're 
>> getting that many signals, the pipe will get full.
>>     
>
> It is OK to lose signals if you have at least one queued in the pipe.
>   

If you're getting so many signals that you can't make forward progress 
on any system call, you're application is not going to function 
anymore.  A use of signals in this manner is broken by design.

>> No point in designing for something that isn't likely to happen in practice.
>>     
>
> You should not design something making the assumption that this scenario
> won't happen.
>
> For example this could happen in high throughput guests using POSIX AIO, 
> actually pretty likely to happen if data is cached in hosts pagecache.
>   

We really just need to move away from signals as best as we can.  I've 
got a patch started that implements a thread-pool based AIO mechanism 
for QEMU.  Notifications are done over a pipe so we don't have to deal 
with the unreliability of signals.

I can't imagine a guest trying to do so much IO though that this would 
really ever happen.  POSIX AIO can only have one outstanding request 
per-fd.  To complete the IO request, you would have to eventually go 
back to the guest and during that time, the IO thread is going to be 
able to make forward progress.  You won't get a signal again until a new 
IO request is submitted.

Regards,

Anthony Liguori

> Its somewhat similar to what happens with NAPI and interrupt mitigation.
>
>   


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