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

                                        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