Re: Questions about kern_descrip.c

2002-07-18 Thread John Baldwin
On 18-Jul-2002 Matthew Dillon wrote: > >:>:-- >:>: >:>: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 li

Re: Questions about kern_descrip.c

2002-07-18 Thread Terry Lambert
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 t

Re: Questions about kern_descrip.c

2002-07-18 Thread Matthew Dillon
:>:-- :>: :>: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

Re: Questions about kern_descrip.c

2002-07-18 Thread John Baldwin
On 18-Jul-2002 Matthew Dillon wrote: > >: >:* Matthew Dillon <[EMAIL PROTECTED]> [020718 11:40] wrote: >:> >:> 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, >:>

Re: Questions about kern_descrip.c

2002-07-18 Thread John Baldwin
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. >:> >:>

Re: Questions about kern_descrip.c

2002-07-18 Thread Matthew Dillon
: :* Matthew Dillon <[EMAIL PROTECTED]> [020718 11:40] wrote: :> :> 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 t

Re: Questions about kern_descrip.c

2002-07-18 Thread Matthew Dillon
:> 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 n

Re: Questions about kern_descrip.c

2002-07-18 Thread John Baldwin
On 18-Jul-2002 Matthew Dillon wrote: > >: >:In revision 1.94 of kern_descrip.c, in the dup2() syscall a goto >:retry loop was added so that if we did a fdalloc() we always retested >:everything. Since fd_nfiles can't shrink and new and old can't >:change, I don't see why the loop is necessary.

Re: Questions about kern_descrip.c

2002-07-18 Thread Alfred Perlstein
* Matthew Dillon <[EMAIL PROTECTED]> [020718 11:40] wrote: > > 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 > M

Re: Questions about kern_descrip.c

2002-07-18 Thread Matthew Dillon
: :In revision 1.94 of kern_descrip.c, in the dup2() syscall a goto :retry loop was added so that if we did a fdalloc() we always retested :everything. Since fd_nfiles can't shrink and new and old can't :change, I don't see why the loop is necessary. Neither dup() or :the F_DUPFD fcntl() were m

RE: Questions about kern_descrip.c

2002-07-18 Thread John Baldwin
On 18-Jul-2002 John Baldwin wrote: > In revision 1.94 of kern_descrip.c, in the dup2() syscall a goto > retry loop was added so that if we did a fdalloc() we always retested > everything. Since fd_nfiles can't shrink and new and old can't > change, I don't see why the loop is necessary. Neither