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