* Terry Lambert <[EMAIL PROTECTED]> [020201 17:02] wrote:
> Bruce Evans wrote:
> > > basically it seems to get pissy if it doesn't get the file slot it asks
> > > for, so if another thread wins the race here, we'll panic.  this problem
> > > seems to also exist for 4.x and previous versions of freebsd.
> > >
> > > I'd like to get this fixed.  Any suggestions?  I think simply
> > > removing the assertion should remove this hazzard, correct?
> I think if you delayed the allocation, it'd be OK, but I don't
> see a clean way to do it without a bit of work.
> > Something like that.  This was apparently missed when the retry loop was
> > added.  Lite2 has the panic but not the retry loop.
> > 
> > BTW, the retry loop also picks up changes to the limit on descriptors.
> > In fdalloc(), the corresponding limit is treated as a loop invariant,
> > but it is not invariant.  I think the process's rlimit can't change,
> > but maxfilesperproc can change even if the process doesn't block, since
> > it is not protected by FILEDESC_LOCK() :-(.  Fortunately, the
> > maxfilesperproc limit isn't very important.
> I think this is a requirement.
> The problem is the case where the maxfilesperproc has *not*
> changed, and some other thread wins the race to the last one,
> you have to honor that, and fail the current attempt.
> Retries are fugly.  8-(.

There's a bunch of bogosity in the ordering of allocation of
slots in the filedesc versus filling out the struct file and
insertion into the list that I need to work out.  I should be
able to take a swipe at it in a couple of weeks hopefully.

-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/

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

Reply via email to