This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: continuation and multi-threading (fwd)
- To: "Joshua Rosen" <rozzin at jello dot geekspace dot com>
- Subject: Re: continuation and multi-threading (fwd)
- From: Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>
- Date: 03 Aug 2000 16:23:09 +0200
- Cc: guile at sourceware dot cygnus dot com
- References: <20000802134537.18643.qmail@jello.geekspace.com>
"Joshua Rosen" <rozzin@jello.geekspace.com> writes:
> He's decoupled the Python stack from the C stack, and implemented
> `incredibly fast' continuations and coroutines with `mutated frames',
Oh, they are implementing call/cc in python?
> according to http://www.stackless.com/spcpaper.htm and
> http://www.stackless.com/stackless.htm.
Hmm, seems like they use solution 5, put all frames on the heap:
----------
[...]
Ergo: The C stack limits the order of execution. You might not
care about order of execution, as a standard user But whenever
you try to play with some special concepts, like co-routines,
generators, or even cooperative garbage collection, then you
always can find some rather easy implementation in Python, but
you cannot try it with C code.
Removing the C stack is cheap. As I try to show in this paper,
the implementation effort is much smaller than one would
think. Execution speed is nearly the same. But the new
possibilities of having an explicit stack are many, and they
cannot even tried in the moment.
They still have a C API, don't they?
Coroutines can be incredibly fast As we will see in the
following, by decoupling the frames from the C stack, coroutines
can be implemented so fast, that it might become feasible to use
them for quite a number of problems. Switching between two
coroutine frames needs just a builtin function call which is much
cheaper than calling a Python function.
Ah, will someone compare them against Gambit->C's call/cc based threads?
Last but not least: PERL has already no longer a C stack.
They will have some good reasons for this. Python has no reason to be limited.
Hmm... Arch.
Jost