Messages in this thread |  | | Date | Wed, 19 Sep 2001 11:59:56 -0400 | From | Zach Brown <> | Subject | Re: [PATCH] /dev/epoll update ... |
| |
> 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/
|  |