Re: [PATCH 05/10] KVM: Adds ability to signal userspace using a file-descriptor

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Davide Libenzi wrote:
> On Mon, 14 May 2007, Avi Kivity wrote:
>
>   
>> Davide Libenzi wrote:
>>     
>>> On Mon, 14 May 2007, Avi Kivity wrote:
>>>
>>>   
>>>       
>>>> Gregory Haskins wrote:
>>>>     
>>>>         
>>>>>> Is having a read() (or a write()) actually necessary?
>>>>>>             
>>>>>>             
>>>>> Based on what I know: yes.  It could be a case of ignorance, however ;)
>>>>>
>>>>> Heres why I think its necessary:  You need poll to simply tell you when
>>>>> something is pending.  You can't clear the pending status in poll
>>>>> because
>>>>> you cannot predict the internal access pattern (e.g. I assume it could
>>>>> be
>>>>> polled multiple times by the kernel without returning immediately to
>>>>> userspace).  Therefore, you need a second method to actually clear the
>>>>> pending "signal", which I use the read() method for.  I can be convinced
>>>>> otherwise, but that was my original thinking.
>>>>>         
>>>>>           
>>>> I think you are right, but am cc'ing an expert. Davide, we're using an fd
>>>> to
>>>> signal something to userspace, but have nothing to actually read() or
>>>> write().
>>>> Is a read() or write() avoidable?
>>>>     
>>>>         
>>> I don't know exactly what you want to do, but signalfd signal de-queueing
>>> competes with the standard Linux signal delivery, if signals are not
>>> blocked.
>>> So if you don't want to read() the signal, you can just leave the signal
>>> unblocked, and it'll be delivered to the signal handler.
>>> You can even leave the signal blocked and avoid read(), but poll() on the
>>> signalfd will always return POLLIN if the sigmask includes the pending
>>> signal.
>>>   
>>>       
>> This is not about a real signal.  We have an fd (for a pseudo filesystem)
>> which wants to indicate its readiness to select(), but which doesn't have any
>> real data to produce.  Is it possible to implement this without a read() or a
>> write()?
>>
>> We're also looking at using an eventfd for this, so this may be moot.
>>     
>
> Do you close the signaled fd after receiving the signal/event? If you 
> don't close it, eventfd will always return ready (POLLIN).
>   

We don't.  Anyway, that's what we thought.  Thanks for the confirmation.


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


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/