> Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us> writes:
> > Random questions:
> >  - Did I just reinvent a square wheel?  (i.e., is this worthwhile at all?)
> 
> I dunno, but first of all, isn't this the same idea as `continuations'
> in Mach?  See:
> 
> Richard P. Draves, Brian N. Bershad, Richard F. Rashid, Randall
> W. Dean. Using Continuations to Implement Thread Management and
> Communication in Operating Systems.  Technical Report CMU-CS-91-115,
> Carnegie Mellon University, October 1991. Also appears in the
> proceedings of the Thirteenth Symposium on Operating Systems(SOSP).

Yes, I'm familiar with that paper, and I'm quite familiar with the
more general concept of continuations, continuation passing style,
etc., as used within Scheme, as well as the less-general form
mentioned in that Mach paper.

This is not quite the same.

The primary difference in this proposal is that the Mach primitives
documented in that paper only provide for invoking continuations
synchronously, whereas with my proposal, the `continuation' runs
asynchronously, and the code triggering it by calling wakeup() is
unaware of whether it's unblocking a regular process, or scheduling a
`continuation' to run asynchronously.

> It also sounds somewhat similar to the scheme proposed by Matt Dillon
> in
> <http://www.freebsd.org/cgi/getmsg.cgi?fetch=918313+0+/usr/local/www/db/text/1998/freebsd-current/19981213.freebsd-current>.

No, this is rather different, in that it leaves a proc both running
and on a sleep queue at the same time (!) so that callers can clean up
locks, etc., before the process blocks.  It strikes me as a
particularly error-prone way to do things, especially when multiple
layers of the system can block.  

In a preemptively scheduled environment, adding a synchronous unlock &
sleep primitive would seem to make more sense than what he's
proposing.

However, he used the name `asleep' first, so I suppose I should pick
another name if we don't want to seriously confuse people porting code
between systems.

					- Bill