If it is accepted, yes... Atomics should take care of racing. We have a lighter context than most functional languages with this proposal: we reassure JavaScript memory is totally mutable (against Erlang/Rust/Haskell).
This keeps the job easier. I was thinking in the worst possibility and we have the easier. Lock, immutability and not shared mutation are the special cases. For these cases, Atomic and Mutex constructs will fit. *Leo Dutra, **on **Facebook <http://www.facebook.com/leodutra.br> **and LinkedIn <https://www.linkedin.com/in/leobr>* 2016-11-02 12:27 GMT-02:00 Bradley Meck <[email protected]>: > Consider: > > ``` > let a = {}; > > alpha: parallel { > a.text = 'hello'; > } > beta: parallel { > a.text += ' world'; > } > console.log(a); > ``` > > This has racing: > * around `a.text` between `alpha:` and `beta:`. > * around `console.log` since `a` could be 1 of 3 values depending on how > threads are scheduled. > > I am stating that such racing/shared mutation should be prevented. Workers > do this by message passing and ownership of transferable data. There could > be other mechanics for synchronization, but I don't see a simplistic > solution. Things like having a read-only view of data partially helps, but > atomics are most likely the proper way to do this if you don't want message > passing and ownership semantics. > > On Wed, Nov 2, 2016 at 9:09 AM, Leo Dutra <[email protected]> wrote: > >> There's nothing about threading that is not problem with Event loop. >> I'd say there's even less problems. >> >> The proposal is a seamless behaviour, equals to what we have now. >> >> Message passing is not a problem of JS developer in the case, but a >> V8/WhateverMonkey problem. >> >> Changing a value inside a multithread async MUST behave in the same way >> of a change inside a single threaded async. The same way, non-referenced >> variables SHALL NOT be scoped in the thread. This is not Java with >> volatiles. This is the plain old JS with clojures, openess and loose bare >> metal control. >> >> Thread interruption is a bad practice anyway. And we could have a Mutex >> class for the specific case or another idea. >> >> Workers are evented and started, not pooled and easy to use. >> >> >> >> *Leo Dutra, **on **Facebook <http://www.facebook.com/leodutra.br> **and >> LinkedIn >> <https://www.linkedin.com/in/leobr>* >> >> 2016-11-02 11:57 GMT-02:00 Bradley Meck <[email protected]>: >> >>> We need to be careful about this, I would never condone adding threading >>> that could share variables that were not intended to be multi-threaded, as >>> such variable access outside of your `parallelize` construct/syntax would >>> need to be message passing when talking to something that is not already >>> written as a parallel structure. A notable thing here is that Shared Memory >>> and Atomics that are in ECMA Stage 2 : https://github.com/tc39/ecma >>> script_sharedmem which would probably need to land prior to me >>> condoning any shared mutable state. >>> >>> Historically, all JS implementations are based upon a job queueing >>> system described by the Event Loop. This is very different from parallelism >>> which could have shared mutable state. All code is guaranteed to have >>> exclusive access to variables in scope until it finishes running, and that >>> the content of those variables will not change from preemption (there are >>> cases where this is not true in the browser with a live DOM). There are >>> alternative discussion recently on Workers : >>> https://esdiscuss.org/topic/standardize-es-worker . I might look there >>> first. >>> >>> In particular, I would suggest taking a look at problems of >>> synchronization, locking, and preemption breaking existing code a bit >>> rather than just stating that green threads are the way to go. >>> >>> On Wed, Nov 2, 2016 at 8:45 AM, Leo Dutra <[email protected]> wrote: >>> >>>> ECMA introduced Promises and async-await in JS. This improves coding in >>>> an amazing way, reducing the control developers need to wrap an AJAX call >>>> or async I/O. >>>> >>>> JavaScript used to be script and not a language. Classes, workers, >>>> sound control, GL rendering, Node.js modules (with OS conversation), >>>> incredible GC strategies and compilation on V8 and Mozilla "monkeys"... the >>>> list goes on and on. >>>> >>>> Almost all the features provided by old mature platforms, like Java, >>>> .NET and etc. For browsers, the newest JS features provide consistent tools >>>> for productivity and quality code. >>>> >>>> But there's a huge step to accomplish. >>>> >>>> ECMA introduced workers. Node.js came up with streams, native process >>>> spawn and libuv thread pool. This is a lot, but not enough. >>>> >>>> All I hear about Node.js is how it is great for quick message I/O and >>>> bad for aggregations and impossible for parallel tasking. Again, we have >>>> workers and processes, but not green threads. >>>> >>>> I invite you to take a quick look at Akka and OTP (Erlang). More than >>>> it, I will argument: workers and process spawn are the latent desire for >>>> parallel and starting one of these are not "cheap" or waiting in a pool. >>>> >>>> We use streams extensively in Node.js and most frameworks hides it from >>>> us. Call it magic, I call it pragmatism. >>>> >>>> Now, async, await, Promises ("Futures")... we can make it all work in >>>> parallel. >>>> >>>> This would explore more libuv in Node.js and browsers could handle it >>>> too, seamlessly. >>>> >>>> Each function could be run in a green thread, pulled from a >>>> browser/libuv pool, allowing Node.js and browsers to process aggregations >>>> and heavy rendering without heavy start costs and complicated message >>>> control through events. >>>> >>>> More, I ask why not, and "single thread nature of JS" looks more like a >>>> bad legacy from old browsers. We can do it in pieces, like the proposed >>>> async-await and, on better days, provide a Parallel API (something like >>>> *parallelize(() >>>> -> { // parallel stuff here })*). >>>> >>>> I wanna leave you with the possibilities in mind and bully this single >>>> thread dogma. >>>> >>>> You have been told. >>>> >>>> *Leo Dutra, **on **Facebook <http://www.facebook.com/leodutra.br> **and >>>> LinkedIn >>>> <https://www.linkedin.com/in/leobr>* >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
