:>:John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
:>     Yes, that makes sense... and it would be fairly trivial
:>     optimization to make.  I suppose you could have fdalloc()
:>     return EAGAIN or something like that to indicate that
:>     it had to cycle the lock.
:But it doesn't really matter if we cycle the lock.  What I described
:is the current behavior, btw.
:John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/

    Well, the original code for dup2() looped to ensure that the
    source descriptor number was still a valid descriptor.  Why
    the dup() code doesn't do this I'm not sure, but I think it 
    needs to.  If you cycle the locks and do not retry, someone else
    could get in and close() the source descriptor and dup2() will
    not return an error when it should.

    Also, do_dup() assumes that the source descriptor is non-NULL.
    If dup2() (and dup()) do not retry then do_dup() can wind up
    getting called with fd_ofiles[old] NULL (race against another
    thread close()ing or dup2()ing over the original descriptor).

    If I remember right, a dup2()/dup2() race was one of the problems
    being explicitly solved by this commit.

                                        Matthew Dillon 
                                        <[EMAIL PROTECTED]>

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to