Date: Wed, 17 Jan 2001 11:50:29 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: John Baldwin <jhb@FreeBSD.org> Cc: current@FreeBSD.org, arch@FreeBSD.org, Soren Schmidt <sos@freebsd.dk>, Randell Jesup <rjesup@wgate.com>, Alfred Perlstein <bright@wintelcom.net> Subject: Re: HEADS-UP: await/asleep removal imminent Message-ID: <200101171950.f0HJoT149144@earth.backplane.com> References: <XFMail.010117112115.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:>:... :>: :>: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 :>:this: :> :> 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 :required. : :-- : :John Baldwin <jhb@FreeBSD.org> -- 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. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101171950.f0HJoT149144>