[lkml]   [1998]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: read() semantics
    >>>>> On Mon, 26 Oct 1998 19:36:07 -0500, David Holland <> said:

    >> 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


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:45    [W:0.020 / U:1.320 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site