>> 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.
David.H> It would be EBADF,
You're right. That's what I meant.
David.H> but I don't think you should necessarily
David.H> assume that I/O in progress will be cancelled. Having such
David.H> I/O continue to completion is not only the reasonable thing
David.H> from an implementation point of view, but also the behavior
David.H> most consistent with the rest of unix. (For example, you
David.H> can still do I/O to unlinked files you have open.)
David.H> actually doing this kind of thing in 2.0.x you're probably
David.H> lucky if you don't cause the dungeon to collapse around
David.H> you. :-/
I wasn't arguing for one semantics or the other---I just asked what
the intended Linux semantics is. (I still don't know.)
Note, btw, that closing a filedescriptor from within a signal handler
does have the effect of "cancelling" the read in progress. I'd say
that if we want to argue for consistency, it would make more sense to
have the clone() case match the signal handler case.
Also, I think the comparison with unlink() is weak. In the unlink()
case, we remove the _name_ of an object, not the object itself. In
the close() case, we get rid of the object itself (namely the
filedescriptor). Once an object is gone, not cancelling pending
operations on that object seems unwise, to put it mildly... ;-)
[I suppose we can argue whether read() is an operation on a
filedescriptor or on the underlying file. I would say it is both
because the implicit fileoffset argument is maintained on a per-fd
basis.]
--david
-
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/