Stackless 3.0 alpha 1 at blinding speed
Bjorn Pettersen
BPettersen at NAREX.com
Mon Apr 21 11:38:50 EDT 2003
> From: David Abrahams [mailto:dave at boost-consulting.com]
>
> Courageous <jkraska at san.rr.com> writes:
>
> >
> > "non local goto" describes it well, but another way of looking at
> > it is as a "first class, user controlled context switch". That's
> > actually the meat of what it is. In unix, theoretically one could
> > set up the heavy weight equivalent of a continuation by the use of
> > setjmp and
>
> Really? I thought longjmp could only go back up the call stack,
> losing any execution context from inner frames. The whole point of
> continuations, AFAICT, is that:
>
> 1. execution context is preserved
> 2. You can transfer control up, down, or between call stacks.
All true, except I would probably call them invocation chains :-) I do
like the term "first class user controlled context switch" though, even
it it only implies continued execution :-)
[...]
> Also, "stacklessness" is really an implementation detail AFAICT - it
> just says that all execution context is stored in
> dynamically-allocated structures instead of using local variables on
> the 'C' stack (via a recursive-calling implementation).
>
> Have I misunderstood this whole thing?
Which property exactly makes the C stack frames not dynamically
allocated? (the sequential property of the allocator, or the fixed size
of the stack itself?)
-- bjorn
More information about the Python-list
mailing list