Messages in this thread | | | Subject | Re: read() semantics | From | David Holland <> | Date | Mon, 26 Oct 1998 19:36:07 -0500 |
| |
> What is the semantics of the read() system call supposed to be if the > file descriptor that is being read gets closed by some other thread? > I'd have expected that read() returns with EINVAL. Instead, it > appears as if a blocked read() keeps the file descriptor open and the > close() isn't noticed until the read() returns.
It would be EBADF, but I don't think you should necessarily assume that I/O in progress will be cancelled. Having such I/O continue to completion is not only the reasonable thing from an implementation point of view, but also the behavior most consistent with the rest of unix. (For example, you can still do I/O to unlinked files you have open.)
actually doing this kind of thing in 2.0.x you're probably lucky if you don't cause the dungeon to collapse around you. :-/
-- - David A. Holland | (please continue to send non-list mail to dholland@cs.utoronto.ca | dholland@hcs.harvard.edu. yes, I moved.)
Any netkit mail should be sent to netbug@ftp.uk.linux.org, not me.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |