Messages in this thread |  | | From | Rusty Russell <> | Subject | Re: [PATCH] thread wakeup fix for 2.4.0-test7 | Date | Sun, 27 Aug 2000 19:48:50 +1100 |
| |
In message <Pine.LNX.4.10.10008261055590.10092-100000@penguin.transmeta.com> yo u write: > No. SuS agrees with me 100%.
My braino. You are completely correct about the close() semantics.
> mmap(fd) > close(fd); > ... the _file_ is still active through the mapping ... > > and the mmap doesn't go away. Nobody expects the mmap() to go away just > because you closed the fd. It's still there - and in fact SuS _requires_ > that it is still there. > > The poll case is 100% the same.
Um, I think not. read/write/mmap/etc. all refer to `the file associated with the open file descriptor'. poll and select actually refer to the file descriptor itself. Usually this semantic difference doesn't matter. In this case it does: any arguments involving congruence with mmap/read are flawed.
Tested 2.2.15 (fd closed, data becomes available) 1) read returns as normal 2) poll returns POLLNVAL, even if it's readable. 3) select will not return EBADF, nor mark fd readable, even if it's readable.
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?
Rusty. -- Hacking time. - 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/
|  |