Greg Ewing wrote:
>
> Jeremy Hylton <jeremy@alum.mit.edu>:
>
> > Are continuations necessary to implement them or are
> > there other options?
>
> I think you'll find that any implementation of microthreads
> or coroutines or whatever you want to call them, that
> doesn't rely on playing nonportable tricks with the C
> stack, will be just as mindbending as Stackless.
>
> > The problem is that continuations break the notion a C API call will
> > always return an answer;
>
> So do threads or coroutines. As soon as you have multiple
> threads of control, you have the chance that one of them
> will switch to another and never get back.
This is correct!
The only "special" thing with my continuation implementation
is that frames are armed to be able to accept a return
from a callee multiple times.
This little piece on top of frames turns them into full
continuations.
Without doing this, the API doesn't change, just the implementation
gets a little simpler.
What remains is still what Greg says:
The guarantee of stack-like frame execution no longer holds,
and every stackless C extension must either provide a way
to handle calls in a tail-recursive manner, *or* it must
enforce stack-like execution, like it is done today.
The *only* thing out of (coroutines, generators, uthreads)
which can be built without breaking this assumption are
the simple ICON-style generators.
But those can be implemented without becoming stackless
at all.
If you want full coroutines, or uthreads, the non-trivial
change of execution-order which Stackless permits *is*
necessary.
The step from there to supporting full continuations
is tiny, can be done easily or left completely.
The order of complexity of the Python implementation
is not increased by continuations.
In fact, supporting uthreads and coroutines and not only
stack-based generators impose the real problem.
That's one of my reasons to support continuations:
Making Python completely coroutine aware, without
tricking the C stack, is 90 percent of the problem.
But after walking that far, there is no reason
to leave the other 10 percent alone.
...
Greg:
> I can't see any way out of this. Continuations/coroutines/
> microthreads are all basically the same thing underneath, and
> they imply an execution model that just doesn't fit well
> with C.
Yes, you understood it completely.
> Maybe we need to reimplement Python in Scheme, and then
> feed it through a good Scheme compiler. SPython, anyone?
I believe the current implementation is quite pleasant
for a lot of people, while it isn't perfectly stackless.
A lot of internal operations could be made stackless by
introduction of a couple more opcodes, turning these
operations into bytecode. This would probably not cost
much speed, since only those code branches are a problem
which cause an interpreter recursion today, anyway.
ciao - chris
--
Christian Tismer :^) <mailto:tismer@tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Kaunstr. 26 : *Starship* http://starship.python.net
14163 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
where do you want to jump today? http://www.stackless.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4