PERFORCE change 108878 for review

[Scott Long]

John Baldwin wrote:
> 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.
> 

Ah, ok, I didn't know that DROP_GIANT had that magic.

Scott