Proposal of Multithread JavaScript

Bradley Meck bradley.meck at gmail.com
Wed Nov 2 15:40:20 UTC 2016


>  XHR does it and is seamless (natively it has to be a thread).

XHR is very different since it does not attempt to change state between
threads in a racey fashion.

On Wed, Nov 2, 2016 at 10:37 AM, Leo Dutra <leodutra.br at gmail.com> wrote:

> Bösch... run, change your name and hide in the mountains or they will burn
> all this heresy.
>
> > There is a difference between thread safety and unexpected event
> ordering in a higher level language..  just because you don't think of it
> in the language doesn't mean it isn't there... Also the js environments are
> multi threaded, it's just those threads are for internals and abstracted
> away from you in a safe way.
>
> Sure. The same safe way we can multithread async and await as I said in
> the first statements. That's what I'm calling seamless.
>
> XHR does it and is seamless (natively it has to be a thread).
>
> That's why all the bragging about racing condition applies as much to this
> multithreading as to current callbacks, promises, asyncs and awaits...
>
> If you will fight against it... fight in the foundations. I'm proposing us
> to keep the flow.
>
> Every async would be run in a thread from a pool. Chained or not,
> infectious or not, sharing variables or not... is an internal change I'm
> proposing here.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161102/6c4507ba/attachment-0001.html>


More information about the es-discuss mailing list