[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Demystifying Continuations
The following is forwarded from the comp.lang.smallscript.design
> Ahh. Now we are getting to what I really wanted to understand
> had presumed correctly that we replace the return context with the
> continuation. What I had not realized was the temporal "set" semantics
> require us to unwind/remove intervening continuations.
> This model is then "exactly" like a block far-return or an exception
> unwinding sequence. Where, the F-B contexts/frames are not just
> They "must" be unwound to preserve any guard/finally handler
> Which means that call-continuation is not that of "replacing" the
> return continuation. It is actually a case of throw/unwind until the
Continuations are usually talked about in Procedural language settings,
not Object Oriented settings. Specifically because a continuation is
easily implemented as a goto.
One of the reasons the picture becomes complex in the OO world is
because of all the throw/unwind logic. For historical purposes, I would
say that a 'normal' continuation would NOT unwind, but would indeed
I believe this behaviour, from your arguments so far, would be
inappropriete in an Object Oriented language. Calling a continuation
within your execution thread should do a throw/unwind.
One of the reasons that threads aren't unwound is because if the
continuation is not from your execution thread (ie; you've picked it up
from an instance variable or some place else) then you don't need to
waste time unwinding back through the last 50,000,000 threads. You can
simple throw them away. This is extremely effecient. But it may not be
entirely 'correct' in the object world.
So you have a choice. You can implement continuations with inconsistent
behaviour by having it do two things:
(a) within the current thread, unwind back to the continuation frame
(b) within another thread, don't unwind, but jump straight to the
(I'll just throw in another thought for you. We've all seen people with
memory problems because they hold on to things that shouldn't be held on
to. Like, a window on a class variable, or the root object on a class
variable.. things like that. Imagine for a second somebody holding
Or you can have consistent continuations that really do behave like a
procedural language and never unwind, but jump straight to the
As you've pointed out, this approach would have significant impacts on
the handler code of SmallScript. This would actually give you something
of an 'aspect' oriented programming approach. Using continuations you
could override several programming features to give you a new aspect on
parts of the system. I'm sure this would play havoc on the security and
managed features of SmallScript.
Here's another thought if you want to preserve unwind behaviour. How do
you handle your execution stack? I know if I'd written a process stack,
I would be modifying it as I go. Lets say we've got a multithreaded
continuation happening. Thread A sets the continuation for itself and
keeps on running.
Thread B tried to call the continuation - it's now too late to do a lazy
copy. You needed to copy the entire thread stack when thread A set the
continuation somewhere. This is extremely costly and reduces the
benefits of continuations.
Of course, if you decide to ignore the unwind problems, then you won't
have to copy the entire thread's execution stack.
In short I'd say you have some options and decisions to make. I'm
guessing you really want to add continuations as a tick in the box to
SmallScript. But it may not be a feasable feature for a secure Object
Oriented Agents System.