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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:18 EST