Messages in this thread |  | | Date | Sun, 27 Aug 2000 05:25:31 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [PATCH] thread wakeup fix for 2.4.0-test7 |
| |
On Sun, 27 Aug 2000, Rusty Russell wrote:
> Tested 2.2.15 (fd closed, data becomes available) > 1) read returns as normal > 2) poll returns POLLNVAL, even if it's readable.
... unless ufds had been swapped out and close() happens from another thread while we are paging it in before copying the data out.
> 3) select will not return EBADF, nor mark fd readable, even if it's > readable.
Ditto.
> AFAICT our behaviour doesn't violate POSIX (although it differs from > Solaris), so the question is: is it OK to leave it as undefined > behavior, and say any program relying on it is buggy?
About the only case when program's behaviour is _not_ undefined with such scenario is the following:
thread A: poll() on array including descriptor n thread B: close(n);do something that leads to event on file that used to be refered by n everything else: make damn sure that no events on that file will happen until B will do its thing.
Subtle, britlle and nonportable.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |