Concurrency support?

Brendan Eich brendan at mozilla.org
Mon Jun 26 15:03:14 PDT 2006


On Jun 26, 2006, at 5:43 PM, Bob Ippolito wrote:

> In the Python world you don't "yield across" anything. Functions  
> that use yield, when called, return a generator object with a next  
> method.

[Bob knows all this, but I bet others on the list don't, so I'll  
elaborate here:]

This makes the returned object an iterator, so it is a subsequent  
g.next() call that starts at the top of the generator function, or  
that resumes "just after" the last yield expression (with value  
undefined) if the generator has already been started.  And for-in  
loops and related structures call .next implicitly (implicit hook  
calling is good when unambiguous and intentional).

g.send(v) resumes so that the send expressions result is v.  You have  
to g.next() or g.send(undefined) once to get things started.  You can  
g.throw(e) to resume as if the send expression threw e.

> 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 implicit").

Apart from the EIBTI doctrine, and I think as important for the  
members of ECMA TG1, is the practical problem of over-constraining  
implementations to be able to save and restore whole native+scripted- 
function call stacks, not simply resume a generator function via  
next, send, or throw.  An optimizing compiler may have to deoptimize  
based on the indirect call relation, which in the presence of  
packages and eval is undecideable, so speculative code generation  
with fallback would be required in full.  A tiny tree-walking  
interpreter may have to switch from natural host recursion to an  
explicit control stack, just to support the proposed feature.

/be



More information about the Es4-discuss mailing list