Proposal of Multithread JavaScript

Florian Bösch pyalot at
Wed Nov 2 15:40:04 UTC 2016

There's a fairly good implementation of co-routines called greenlets for
python. It depends on a few basic API calls, these are:

   1. g = greenlet.greenlet(fun) // makes a new greenlet pointing to the
   given function
   2. g.switch(args) // switches to that function
   3. g.switch(value) // once started delivers value inside that functions
   switch call
   4. g.throw(error) // raises an exception into the function
   5. greenlet.getcurrent() // returns the currently running greenlet

With these API primitives, you can implement any flavor of
asynchronous/concurrent scheduler on top if you wish to do so.

On Wed, Nov 2, 2016 at 4:25 PM, Florian Bösch <pyalot at> wrote:

> On Wed, Nov 2, 2016 at 4:13 PM, Bradley Meck <bradley.meck at>
> wrote:
>> Florian, one of the great aspects of generators and async functions in
>> ECMAScript is that they are explicit. It makes understanding where
>> synchronization might need to occur very easy to find. I am unsure what
>> your proposal to prevent infection as you call it would look like if it is
>> explicit.
> The theory that await/async are explicit is nice, but flawed, and here's
> why.
> If you have a call stack of say A -> B -> C -> D, and you change D to
> async D, you have a problem. C isn't awaiting D, so it needs to do C await
> -> async D, but now C isn't async and B isn't awaiting C, and so forth. So
> you'll end up with an "infection": A await -> async B await -> async C
> await -> async D.
> The infection spreads from down the call-stack upwards, and in doing so,
> it spreads sideways as well. If you have say a routine that calls a bunch
> of functions in succession:
> A(); B(); C(); D(); and for some reason or other (because your lower level
> framework code became async) all of them now become awaitable as well, you
> end up with await A(); await B(); await C(); await D();
> So eventually most calls end up being prefixed by await and most
> functions/methods end up being async, except for low-level code deep down.
> It might surprise you that co-routine schedulers work exactly like that.
> Except without all the not needed line-noise. In fact, it could be argued
> that instead of liberally strewing await/async randomly through your code,
> you could simply do a preprocessor that converts every call to an await and
> every closure to an async, that way at least you don't need to type it out
> everytime. Of course you'd also get functionally true co-routines via a
> fairly mindless application of preprocessing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list