From owner-freebsd-arch Wed Jan 17 12:15:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 930BB37B400; Wed, 17 Jan 2001 12:15:24 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id f0HKEta49433; Wed, 17 Jan 2001 12:14:55 -0800 (PST) (envelope-from dillon) Date: Wed, 17 Jan 2001 12:14:55 -0800 (PST) From: Matt Dillon Message-Id: <200101172014.f0HKEta49433@earth.backplane.com> To: Jason Evans Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: HEADS-UP: await/asleep removal imminent References: <20010117100954.S61852@canonware.com> <20010117112232.U61852@canonware.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG One advantage to passing a condition variable back explicitly rather then storing it indirectly in curproc, aka something like this: condition *cv = NULL; rc = majorsubsystemroutine( ...., &cv) Is that it explicitly defines the API. If the procedure takes a condition variable, then you know the procedure might have a blocking condition associated with it which you must handle. If the procedure doesn't take a condition variable, then you know that the procedure is non-blocking(1) AND does *not* produce a blocking condition. In the indirect 'store in curproc' case you can't easily tell. So in that respect I really like the idea of passing the condition variable back through the subroutine layers explicitly, even though I don't like the idea of polluting existing APIs with the additional argument. One thing is absolutely crystal clear to me though: You cannot under any circumstances enqueue the process on the condition variable at the time it is passed back. You can only enqueue the process when you actually intend to go to sleep. Otherwise it wouldn't be an efficient enough interfafce. note(1): well, you don't know that it is non-blocking, because obviously many high level procedures like system calls will block inherently and not return any sort of condition variable. But for LOW LEVEL procedures the definition can hold true and would go a long way to reducing the confusion in the codebase. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message