RE: [PATCH/RFC] POLLHUP tinkering ...

[Davide Libenzi <davidel@xmailserver.org>]

On Sun, 8 Jan 2006, David Schwartz wrote:

>
>> From: Davide Libenzi <davidel@xmailserver.org>
>> Date: Sun, 8 Jan 2006 16:02:10 -0800 (PST)
>
>>> But if and hangup happened with some data (data + FIN), they won't
>>> receive any more events for the Linux poll subsystem (and epoll,
>>> when using the event triggered interface), so they are forced to
>>> issue an extra read() after the loop to detect the EOF
>>> condition. Besides from the extra read() overhead, the code does not
>>> come exactly pretty.
>
>> The extra last read is always necessary, it's an error synchronization
>> barrier.  Did you know that?
>
> 	If there is an error, an error event must be returned. An edge-triggered
> interface must report every event that occurs with an indication of that
> type.

Yes, that's the case.



>> If a partial read or write hits an error, the successful amount of
>> bytes read or written before the error occurred is returned.  Then any
>> subsequent read or write will report the error immediately.
>
> 	If the connection closes and the edge-triggered interface does not give a
> HUP indication, then it is broken.

Same as above. I think DaveM was thinking at the classical poll/select 
usage scenario, where the wait queue head stays in the device's wait queue 
only during the poll/select system call. With epoll, they're resident and 
always collection events through wakeups (callbacks in the epoll case) 
done by the device on its poll wait queue.



- Davide