PERFORCE change 108878 for review

[John Baldwin]

On Thursday 02 November 2006 12:10, Scott Long wrote:
> John Baldwin wrote:
> > On Thursday 02 November 2006 06:22, Hans Petter Selasky wrote:
> > 
> >>On Wednesday 01 November 2006 16:47, John Baldwin wrote:
> >>
> >>>On Tuesday 31 October 2006 20:12, Scott Long wrote:
> >>>
> >>>>http://perforce.freebsd.org/chv.cgi?CH=108878
> >>>>
> >>>>Change 108878 by scottl at scottl-x64 on 2006/11/01 01:11:30
> >>>>
> >>>> For some wonderful reason, you cannot pass &Giant to msleep.  Work
> >>>> around that in a crude fashion.  Also add some more assertions.
> >>>
> >>>Ah, yes, that would be most unhappy.  I guess mostly the idea is that Giant
> >>>should be rather implicit and explicitly using Giant for an object lock is
> >>>discouraged.  I'm not sure that is what you are doing though.  I think
> >>>maybe you are borrowing Giant that's already held?
> >>
> >>I use this patch:
> >>
> >>/* preliminary fix for a bug in msleep on FreeBSD, 
> >> * which cannot sleep with Giant:
> >> */
> >>#define msleep(i,m,p,w,t) msleep(i,(((m) == &Giant) ? NULL : (m)),p,w,t)
> >>
> >>Really this issue should be fixed. It happens just because GIANT_DROP is done 
> >>too early in "msleep()".
> > 
> > 
> > Giant is special in msleep() and friends to make sure it is first in the
> > lock order, but unlock doesn't matter for lock order, and actually, the
> > current order is less intuitive.  I think it's the way it is now because we
> > inherited it from BSD/OS.  Also in theory old code under Giant should be
> > using tsleep() and not msleep() anyway.  It actually won't hurt to move
> > DROP_GIANT later though.
> > 
> > How about this:
> > 
> 
> This won't work for what I'm using it for.  It's not a big deal, though.

?  It should make msleep(&Giant) work just the same as msleep(&foo).  In this
case if Giant is only singly locked, DROP_GIANT just won't do anything.

-- 
John Baldwin