Concurrency support?

Bob Ippolito bob at
Mon Jun 26 14:43:14 PDT 2006

On Jun 26, 2006, at 2:09 PM, Chris Double wrote:

> On 6/27/06, Brendan Eich <brendan at> wrote:
>> Yes, and that is a concern for us, for Rhino's Continuation object
>> implementation (which cannot cross Java native frames), as for
>> Python.
> There are ways around the inability to yield across C stack frames. A
> Jit was recently announced for Lua that supports yielding from C
> functions and returning to them (provided by the Coco patch):
> I like the addition of generators to Javascript but not being able to
> yield from functions called from the generator is a pain. But that
> model has been in use for a while in the Python world - do they find
> it a practical limitation?

In the Python world you don't "yield across" anything. Functions that  
use yield, when called, return a generator object with a next method.  
The next method executes the function until a yield or an exception 
[1] and returns the value yielded. Generators help out considerably  
for a lot of use cases, but they're definitely not equivalent to  
coroutines in any practical sense. This isn't generally considered to  
be a pain, because generators aren't purporting to be coroutines and  
most users aren't going to be familiar with something like call/cc  

PEP 342 turns yield into an expression that has a value or may raise  
an arbitrary exception depending on what the caller does (by adding  
the send and throw methods). It allows for coroutine-like behavior,  
but the user has to implement it with a trampoline and write code in  
a sort of communicating sequential processes style. It does not allow  
for "magical" behavior like implicit cooperative threading on I/O.  
 From the Python design perspective, this is generally considered to  
be a good thing according to EIBTI[2] ("explicit is better than  

[1] bare return and falling off the end of the function are  
equivalent to "raise StopIteration".


More information about the Es4-discuss mailing list