Date: Wed, 17 Jan 2001 12:14:55 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Jason Evans <jasone@canonware.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: HEADS-UP: await/asleep removal imminent Message-ID: <200101172014.f0HKEta49433@earth.backplane.com> References: <20010117100954.S61852@canonware.com> <XFMail.010117105509.jhb@FreeBSD.org> <20010117112232.U61852@canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101172014.f0HKEta49433>