:>: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.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message