Messages in this thread | | | Date | Sun, 8 Jan 2006 20:55:44 -0800 (PST) | From | Davide Libenzi <> | Subject | RE: [PATCH/RFC] POLLHUP tinkering ... |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |