On 18-Jul-2002 Matthew Dillon wrote:
>:>     The issue with dup2() was a race against open() or close()
>:>     I believe, where dup2() could potentially dup into a
>:>     descriptor that open() was about to use.  Unfortunately, it
>:>     does appear that dup() has the same issue.
>:>     fdalloc() does not reserve the descriptor number it
>:>     returns, it simply finds a free slot and says 'this
>:>     index is a free slot'.  Even in the latest -current,
>:>     fdalloc() releases the fdp lock when it goes to
>:>     MALLOC so the race appears to still be present.
>:Well, execpt that if we malloc(), we then grab the lock and loop
>:again.  If we return without an error, it means we reserved a slot
>:while holding a lock and returned with the lock still held.
>: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/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

Reply via email to