lkml.org 
[lkml]   [1998]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: read() semantics
From
Date
 > 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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.063 / U:0.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site