Concurrency support?

[Bob Ippolito]

On Jun 26, 2006, at 3:58 PM, John Cowan wrote:

> Brendan Eich scripsit:
>
>> 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.
>
> I don't follow this.  A tiny interpreter will have to escape from
> natural host recursion anyway just in order to do simple Python/Icon
> generators, and I don't see that yielding within C functions is
> so essential to the concept -- I'd be happy with just what Lua
> (unJITted) provides.

I have no idea what you mean by "natural host recursion", but I have  
a feeling that you're mistaken. Python's implementation of generators  
simply keep the generator's frame around (the gi_frame attribute on  
the generator object). The frame stores all of the locals and the  
bytecode offset. Calling the next() method just resumes the  
interpreter at whatever bytecode it was at. It's not written in CSP  
style and it doesn't require any weird tricks.

The only real difference between a generator frame and a regular  
frame is that the regular frame is tossed after the function returns,  
where a generator's frame is kept around until the generator is  
garbage collected.

You can't really write generators in C, but you can easily write  
iterators -- objects that have a next() method that behave according  
to the iterator protocol. From a user's perspective, these two kinds  
of objects are intentionally indistinguishable since generators are  
just a convenient syntax for implementing an iterator.

-bob