Sorry...

let a = {};

async alpha() { a.text += 'hello' }
async beta() { a.text + ' world' }

parallel.all( a, b ) // or thread.parallel( a, b )
.then(() -> console.log(a.text))


*Leo Dutra, **on **Facebook <http://www.facebook.com/leodutra.br>
**and LinkedIn
<https://www.linkedin.com/in/leobr>*

2016-11-02 12:46 GMT-02:00 Leo Dutra <leodutra.br at gmail.com>:

> This is not only easier, this is faster.
>
> We have a single memory allocation and all the threads share it.
> Considering your case:
>
> let a = {};
>
> async alpha() { a.text += 'hello' }
> async beta() { a.text + ' world' }
>
> parallel.all( a, b ) // or thread.parallel( a, b )
> .then(x -> console.log(x))
>
> Will output ' worldhello' or 'hello world' like any multithread platform
> will.
>
>
>
> *Leo Dutra, **on **Facebook <http://www.facebook.com/leodutra.br> **and LinkedIn
> <https://www.linkedin.com/in/leobr>*
>
> 2016-11-02 12:39 GMT-02:00 Leo Dutra <leodutra.br at gmail.com>:
>
>> 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 <bradley.meck at gmail.com>:
>>
>>> 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 <leodutra.br at gmail.com> 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 <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/ecmascript_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/0063ee97/attachment-0001.html>

let a = {};

async alpha() { a.text += 'hello' }  
async beta() { a.text + ' world' }  

parallel.all( a, b ) // or thread.parallel( a, b )  
  .then(() -> console.log(a.text))

Will output ' worldhello' or 'hello world' like any multithread platform
will.

let a = {};

async alpha() { a.text += 'hello' }  
async beta() { a.text + ' world' }  

parallel.all( a, b ) // or thread.parallel( a, b )  
.then(() -> console.log(a.text))

Will output ' worldhello' or 'hello world' like any multithread platform
will.

let a = {};

async alpha() { a.text += 'hello' }  
async beta() { a.text + ' world' }  

parallel.all( a, b ) // or thread.parallel( a, b )
.then(() -> console.log(a.text))

Will output ' worldhello' or 'hello world' like any multithread platform
will.

let a = {};

async alpha() { a.text += 'hello' }
async beta() { a.text + ' world' }

parallel.all( a, b ) // or thread.parallel( a, b )
.then(() -> console.log(a.text))

Will output ' worldhello' or 'hello world' like any multithread platform
will.

Sorry...

let a = {};

async alpha() { a.text += 'hello' }
async beta() { a.text + ' world' }

parallel.all( a, b ) // or thread.parallel( a, b )
.then(() -> console.log(a.text))