:>:The lock must be unwound becasue we're calling MGETHDR with M_TRYWAIT.
:>:If wae used M_TRY'A'WAIT the code would probably look something like
:>     The basic premis of using asleep()/await() is to allow you to
:>     propogate a 'blocking condition' back up to a higher level rather
:>     then blocking deep in side the kernel.
:Gotcha.  Given that, if we switch to using condition variables for this, why
:not have the low level code return a pointer to a cv to wait on?  This would do
:the same thing using an existing API (now) and I think would serve the same
:purposes as your API.  Returning NULL for a cv would mean that no sleep was
:John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/

    You could but that would require massive changes to the API for 
    many of the calls.  It's probably easier for the low level code
    to passively install the pointer into the proc structure and
    return 'NULL' - which is more likely to already be supported 
    or mostly supported by the API.  Don't get me wrong, the caller
    needs to know what is going on, but there is something to be
    said for not passing yet another argument to half the procedures
    in the kernel :-)

    One of the best things about a passive pointer in the proc
    structure as per my proposal is that the caller can decide to
    ignore it, can NULL it out, can leave it in place and propogate
    the failure upwards, or can replace it with another condition
    pointer.  This gives the caller an incredible amount of flexibility
    in how it decides to handle the blocking condition, all without
    introducing any overhead.


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

Reply via email to