Concurrency support?
Brendan Eich
brendan at mozilla.org
Mon Jun 26 18:08:33 PDT 2006
> 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 mean by natural recursion that each activation of an ES function
is interpreted by a host (let's say C) function. Unwinding and
winding back through C functions requires mangling them to use
explicit control state, or else using something akin to a user-level
thread (setjmp/longjmp, setcontext, etc.).
With the Pythonic generators currently proposed for ES4, there's no
need for such host stack saving and restoring. As Bob pointed out,
you just need to save the generator function's frame.
Native C functions don't have to be involved for this stack saving/
restoring to be an unwanted burden, but if you propose to allow yield
to "return across" many frames, then it's hard to avoid a native
frame creeping into the stack that's being crossed, and then you
definitely need user-level threads, safe stack allocation with
redzones for overflow, etc. That's too costly for small
implementations.
Murphy was an optimist, and abstraction favors allowing arbitrary
native or ES implementation of any function in a large program.
/be
More information about the Es4-discuss
mailing list