> I have some immediate uses for a kcont-like interface; so any feedback
> on this would be appreciated.

I think you need a SA like behavior for your process context continuations.
When a continuation blocks - add a new worker thread.
Otherwise you might add hidden dependencies leading to deadlocks.
( Well you probably have to limit the # of threads .. but it is something to
keep in mind )

You can also add some parallelism by using one thread per CPU.

Adding priorities to process context continuations would also be desirable
- especially once NetBSD gains in kernel preemption.

The framework looks nice - with the exception of kcont_defer_malloc
where I fail to see how you could recover from a failed allocation.

I like it - I am just wondering if some additional infrastructure
would allow code using continuations to be less complex.

OK - here are some initial thoughts about this to start
some discussions - I reserve the right to change my opinions once
I had time to really think about it ;-)

I played with continuation once on a C++ project where strange requirements
forced me to a strange design. (Scaling from system with threads down to
systems requiring shared memory and I/O processes)

Error handling in continuations add a lot of coding complexity
and I am especially worried about memory allocation.

I am wondering if it would be beneficial to offer any continuation
function a way to "call me again when I can allocate some memory".
( Or allocate memory - and then continue me)

While the real benefit of continuation is the ability to do things
parallel and out of order - there are also a lot of instances where
you end up with hierarchical continuations.
( Yes you could flatten everything .. but this becomes unmaintainable real fast)

Having an argument stack associated with the continuation 
( MS's IRPs come to mind ) can also eliminate some error checking and is probably 
easier on the cache.
( Yes a parent continuation would have to check the stack space for non-checking
 children)
 

	Stephan