Proposal of Multithread JavaScript

Florian Bösch pyalot at
Wed Nov 2 15:25:27 UTC 2016

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

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