On Sun, 8 Jan 2006, David Schwartz wrote:
From: Davide Libenzi <[email protected]>
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
