Re: read() semantics

David Holland (dholland@cs.toronto.edu)
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/