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
