> Stevens [UNPV1, in chapter on nonblocking accept] suggests that readiness
> notifications from the OS should only be considered hints, and that user
> programs should behave properly even if the OS feeds it false readiness
> events.
[ ... ]
> That said, the principle of least suprise would suggest that /dev/epoll should
> indeed return an accurate initial status. There are a lot of programmers who
> don't agree with Stevens on this issue, and who write code that breaks if you
> feed it incorrect readiness events.
They're living a lie :) A readiness event does not guarantee future
operations, it provides a hint of the status of things at the time the
event was generated. Networking events can happen that change the status
of sockets from when readiness events come in and when the app tries to
react to them..
- kernel gets ack, freeing tx queue space
- the kernel wakes up the task with some POLL_OUT event
- a packet comes in from the wire that resets the socket
- the app sees poll_out and tries to write, and is surprised
there are many more situations like this. readiness is _always_ only
a hint, and the app has to deal with this.
- z
-
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/
This archive was generated by hypermail 2b29 : Sun Sep 23 2001 - 21:00:30 EST