Re: coroutines and continuations ( in Python? - long discussion )
Fri, 06 May 1994 00:16:06 +0200

> However, one of my other points burried somewhere in that discussion
> was that threads could be supported more portably by building
> coroutines into the interpreter virtual machine. Python byte-code
> instructions and builtin-C functions would then be 'atomic'. ( This
> has some good and some bad implications, which I haven't thought thru
> yet. ) Whether a coroutine/continuation syntax should show thru to the
> Python language level is another question. I'm interested in exploring
> that option, but the two questions are independent.

But C calls are NOT atomic -- C code can call back to Python. This
currently happens in a number of built-in functions, e.g. apply(),
map(), filter(), reduce(), and don't forget exec, eval() and import!

While these may be thought of as part of the implementation and
somehow mendable (e.g. by returning the code object to be executed
instead of executing it directly), another category which is harder to
argue with are callback functions from libraries, e.g. Xt/Motif

We could make these special cases not to be messed with in coroutines,
but it would mean that occasionally there would be a set of execution
environments separated by a bit of C stack that could not talk to each

> I've finished my sci-fi book, so my silence on these matters has been due
> mostly to the fact that I'm actually tring to figure out an implementation so
> I CAN play with it. If I give up on coroutines and/or continuations in
> the *language*, my fall back is to try to support portable threads via
> this mechanism.

BUt portable threads would siffer from the same problem!

--Guido van Rossum, CWI, Amsterdam <>
URL: <>