In message <20040401041035.16173.qmail@web41203.mail.yahoo.com>Gary Thorpe writes

>Are continuations directly related to thread migration (not moving
>between CPU's but moving say a client's thread into the server to do
>the work for the client)? The mail archive kind of suggests this, so I
>am just curios - are they based on the same concept or are they just
>coincidentally similar?

kcont in NetBSD has absoutely nothing to do with this idea.

kcont is a way for an in-kernel subsystem to bundle up its internal
state, request some other operation -- say, an I/O request, or
interacting with a socket -- and to pass that operation enough state
for the first kernel subsystem to pick up from where it left off,
before it was so rudely interrupted by the I/O operation.

The classic Unix mechanism to achieve this is to use a process context
and have it sleep(9) on an address; the I/O operation issues a wakup()
on the slept-upon address. This is all described in the classic
papers: (BSTJ, July/August 1978 Vol. 57, No. 6., Part 2).
sleep has since become tsleep and ltsleep, but the idea remains the same.

kcont offers an alernative where the *_caller* gets to specify how to
notify it of I/O completion; and avoids the overhead of going through
the fullblown Unix schduler.

At this point I could mumble about how kcont is (modulo the
limitations of C) isomorphic, to a Common-Lisp manual translation into
continuation-passing style (CSP) rather than true Scheme-style
continations. But that's probably not helpful to most of tech-kern,
and the people who'd find it useful are, uh ... already making jokes
about it in offlist email.