leodutra.br at gmail.com (2016-11-02T14:24:33.464Z)
Understood about shared mem. I agree a declared shared space is faster and more manageable than a considering all shared. As I said, we could use JIT to determine that or use the long reserved word "volatile": volatile var foo = "Shared string" Accessing a non-volatile variable SHALL resolve to a copy like all the other platforms resolve. I don't like to refer to others, but this is a problem industry resolved a long time ago.
Understood about shared mem. I agree a declared shared space is faster and more manageable than a considering all shared. As I said, we could use JIT to determine that or use the long reserved word "volatile": volatile var foo = "Shared string" Accessing a non-volatile variable SHALL resolve to a copy like all the other platforms resolve. I don't like to refer to others, but this is a problem industry resolved a long time ago. *Leo Dutra, **on **Facebook <http://www.facebook.com/leodutra.br> **and LinkedIn <https://www.linkedin.com/in/leobr>* 2016-11-02 12:22 GMT-02:00 Leo Dutra <leodutra.br at gmail.com>: > Understood about shared mem. I agree a declared shared space is faster and > more manageable than a considering all shared. > > As I said, we could use JIT to determine that or use the long reserved > word "volatile": > volatile var foo = "Shared string" > > Accessing a non-volatile variable SHALL resolve to a copy like all the > other platforms resolve. > > I don't like to refer to others, but this is a problem industry resolved a > long time ago. > > > > > > *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 <bradley.meck at gmail.com>: > >> 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 <leodutra.br at gmail.com> 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 >>> es-discuss at mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161102/98c81098/attachment-0001.html>