Subject: Re: Prototype kernel continuation-passing for NetBSD
To: Gordon Waidhofer <firstname.lastname@example.org>
From: Lennart Augustsson <email@example.com>
Date: 01/29/2004 01:31:10
Call/cc is definitly a beast (but it can be a useful one).
But there is no need to go that far just because you use
The idea of continuations is very simple:
instead of having a function return its result, the function
will get passed an extra argument; this extra argument is
a function that will be given (i.e. called with) the result at
the point where a regular function would have returned.
There, that wasn't so bad, was it? :)
Gordon Waidhofer wrote:
>>Do you have any recomended reading for those of us who aren't
>>familiar with continuations? :-)
> There are surely better answers, but here's an answer....
> Continuations are hard to sum up in a nutshell. See the
> Scheme procedure call-with-current-continuation, aka call/cc.
> I tried to find a short, illuminating description. Short is
> possible. Illuminating, well.....
> Continuations proper can be thought of as setjmp/longjmp
> on steroids. If foo() calls setjmp(jb), you can not pass
> jb to longjmp() after foo() returns. That's setjmp()/longjmp().
> But call/cc allows "unlimited extent", meaning jb remains
> valid until you abandon it or kill it. You can even use jb
> an unlimited number of times. It amounts to copying
> the stack. That's continuations proper, in a nutshell. It is
> a pale explanation compared to what's possible.
> The kcont mechanism posted is a nice framework for
> callbacks, as the poster (Johnathon Stone) said.
> I can see how it took its inspiration from continuations.
> All the fiddling to get spls() right for callbacks,
> sequencing, off-level deferal, etc, etc, are kinda
> bundled up here. It looks like one of those things
> that, once you get used to it, you wonder how you did
> without it. We all do the same sorts of things all
> the time without the framework.