It's a long posting, so I hope that I haven't violated any community
rules and that this problem will interest somebody enough to comment.

To match the title, I'll start off with a quoted blog posting retrieved
from the ether by the Wayback Machine from Pinku Surana.  The actual
blog seems to have disappeared when Northwestern University's CS
department reorganized their website.

Here's the place for the alt.os.development guys to get interested.

I discovered that such a thing could be done with threads.  I could
implement two operators:

Fork() - Unix-style fork that returns the identifier of the child thread
or an identifier of the invoking thread.
Invoke(thread) -> identifier - Runs thread, passing it the identifier of
the current thread (the one that called Invoke).  Invoking a thread
causes it to return the "current thread identifier" either from the
Fork() that created it or the last Invoke() it called.

Lispers take note: doesn't that Invoke look like applying call/cc to a
continuation?  I noticed the resemblance, and decided to switch from
threads over to continuations.

Doing so instantly made kernel programming more elegant.  Instead of
threads that could be valid to operate upon (ie: contain program state)
*or not* at any time, I ended up with "virtual processors" that contain
the OS state of a running continuation and "saved continuations" that
contain the state of reified continuations.  A continuation is the
contents of the saved processor.

Of course, some concessions must be made to the fact that we're talking
about an operating system kernel written in Object Pascal that wants to
interoperate with C -- lack of garbage collection and closures and
inefficiency of copying a full machine continuation (ie: all user- and
kernel-level machine state one would normally find in a thread or
process).  So I end up with this set of operators:

CallCC(entry,closure) -> value - Calls procedure entry of two
parameters, one a continuation and the other a pointer, passing the
reified calling continuation as the first argument and closure as the
second (to provide for pseudo-closures in non-closure languages).  Entry
is called in an entirely new continuation created by the kernel.

Throw(continuation,value) - Passes value to continuation and throws to
continuation, causing the original CallCC to return value.  Destroys the
calling continuation.

CallCC(continuation) -> value - Throws to continuation, passing it the
current continuation (which is not destroyed) instead of an arbitrary value.

Copy(continuation) -> continuation - Copies the given continuation.

Destroy(continuation) - Destroys the given continuation.

These are one-shot continuations, but given Copy implementing
multiple-use continuations in user-space shouldn't be very tough.

Lispers, you come in *here*, as we start talking about the use of
continuations for concurrency.

Concurrency (on shared-memory multiprocessor systems) comes easily:
simply create a virtual processor for each physical processor the
operating system sees.  A master processor starts each one up with a
continuation, and they pretty much run themselves concurrently.  If a
scheduler is present in user-space, any number of virtual processors can
access it by running continuations that act as coroutines of that
scheduler.  The kernel supplies mutexes based on a TSL instruction.

Of course, if that seems like a stupid concurrency model to you, only
say so!

Now here's the hard bit: asynchronous events.  I define them here as
tasks that run in response to asynchronous events or signals from
hardware or software, ie: generalized interrupt handlers.  In most
microkernel systems (like L4) the kernel simply translates an event into
a message that gets sent to some handler process, which handles the
event by receiving the message in its own time.

But we're talking about a continuation-based kernel, in which there's no
scheduler to run that handler process.  Event handlers also need some
mechanism to handle the task they interrupted to implement more
conventional preemptive multiprocessing models.

That can easily be accomplished by running an event handler via CallCC.
 The mechanism I use to implement a continuation switch runs at the
completion of an Interrupt Service Routine, so handling interrupts with
events with CallCC's leaves a pretty low interrupt latency.

Now the question is: *how do you make that fast*?  Interrupt handlers,
even if they don't run in the ISR itself, must run fast enough that the
interrupted continuation doesn't suffer unduly.

How do you think that should work?  The next bit is the solution I
worked out, and an alternative that just occurred to me.

<Spoilers>
I decided to bring back the persistence (continued existence across
operations) of threads by creating "persistent continuations".  These
come in one of two states: "filled" or "empty".  References to a
persistent continuation from user-space are only valid when that
continuation is in the "filled" state, which it only obtains from being
reified by CallCC.  However, internal references to the continuation
held by the kernel are always valid, because the actual lifetime of the
persistent continuation is managed by reference counting.

Now here's the trick: Throw()'ing a persistent continuation saves the
current continuation from the virtual processor to the persistent
continuation structure instead of deleting the continuation, but sets
the continuation's state to "empty".  So the user thinks the
continuation no longer exists, while the kernel event-handling machinery
sees a continuation filled with data.  Then, when the event handler must
be run again, the kernel passes the "empty" persistent continuation to
CallCC, resuming it.

In short: event handlers act like threads (running, suspending
themselves, and running again), while normal computations act like
continuations (running and terminating or running and reifying).

Of course, being able to CallCC to a continuation that suspended itself
on a Throw means somehow passing the Current Continuation that puts the
CC in there to the called continuation passed explicitly to CallCC.  Put
simply, Throw needs to start returning a continuation, *but only for
persistent continuations*.  The normal kind get destroyed as before.

The kernel internally converts a normal saved continuation to a
persistent continuation when it saves that continuation as an event handler.

Note that by CallCC'ing to a continuation on an event and Throw'ing to a
continuation (the interrupted one or a new one) at the end of the event
handler, saving the state of the event handler in a continuation as a
side-effect, these performance gains are made:

1.No continuations are created when an event is handled, except by
explicit request of user code.  This includes Copy'ing.
2.No continuations are destroyed when an event is handled, except by
explicit request of user code.
3.Event handling system calls only need to be invoked once for a
continuation to handle the given event forever.
4.The total overhead of an event handler (time and dynamically-allocated
memory not spent in the interrupted continuation or the event-handler
continuation) drops no memory at all and two context switches (one to
the handler, one out of it).

But now Throw() is a leaky abstraction, a routine that sometimes returns
and sometimes doesn't according to the whims of the kernel.  Any more
elegant way to handle asynchronous events quickly?
</Spoilers>