RE: Proposal of Multithread JavaScript
Isiah, the only serialization, or at least heavy one, in DOM is .innerHTML and some other textual stuff. Appending moves pointers and references in the internal DOM representations (a real problem in old browsers like IE was this representations ran in another host Engine). Appending nodes are blazing fast... And is structural code, not evented as the bad message passing of spawned processes in Node or Web Workers. Isiah, I'm used to cluster, maybe more than I'd like. I'm very used to Java threads, and now on Java 8 a Runnable is a Functional interface implementation (means in Java that Runnable.run() became a simple lambda function). This is more than enough similar to what a JS function could either be on a thread API. If Node abstracted process as a kind of Host object like a DOM Node, messaging would be lighter and probably serialization would be done at C levels, not on JS strings / stringify level. Java Threads are part of a scope, Node clusters are not. This implies speed, scoping and control differences enough to say Workers/clustered processes are way different from what I propose. And more, cluster process or process spawn or Web Workers require a particular separated JS ( or you will do dirty stuff putting run JS together with massive ignored JS). A thread would be as simple as: thread.run( (thrd) => console.log(thrd.id) ) A simple "callback"/ stream/ whatever you call run out of Event Loop. A while(true) would not lock any other JS operation. That's the most powerful part of thread spawn and to allow JS devs to do it is much. This with indication for components, like XHR, to run callback in a threaded function out of Event Loop. Event Loop should do all that Node does and People say it does good: io messaging and no aggregation / loop intensive stuff. There's no reason to care with mutability since callbacks mutated values today and most new js devs already think it is running on a parallel process (many many people will even call you crazy if u say). Again, think in a function as any callback today, but running out of the EL. I can't make a more realistic metaphor. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
Why would UI/DOM access need to be serialized? And Windows is a great reference of what not to do. .NET as a whole too, since all before C# 6 comes from bad MS and all after is copied from somewhere. NT should be thrown away and be replaced by a sweet BSD layer The only thing they did well are Registered I/O. Threads are not that good in Linux because a process starup in Linux is blazing fast... And the work are not that great; except when you have a thread pool, and a process pool is quite not possible (at least I've never seen one for general application software). Hard work is not a reason to discard a gamechanging enhancement. There's many enterprises which prohibit devs from using threads and some other language features... They presume retard devs. A bad developer is not JavaScript issue. A JavaScript issue is the impossibility of doing something Java, C, C#, Python, Scala, Haskell, Go and a bunch more do with a simple keyword or method. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
I have defined many times, but you guys are in love with workers. A little look in Java's Runnables would demonstrate de nature and difference I'm bringing to this thread. Workers can't even modify DOM directly... Very different of go routines, Java/Scala threads etc. Workers require way more control and coding by the nature of their declaration and messaging. A worker lives and awaits... A thread is run against a living spawned process and is garbaged after the usage. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
Workers need serialization, threads would not. In Node, lack of threading requires a prior spawn of a bunch of native processes and manually build a tasking pool. Web Workers spawn a specific script (if you respawn the caller you are doing dirty job). Maybe we should fork projects like the one Isiah brought to us and headbang compiling it with the lovely gyp. So much emotion. Much doge work. So delicious. You could simply spawn a thread in almost the same way we use Node streams... but I won't fight 10 guys alone. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
We could think in a pool of workers with dynamic code execution or propose, in JS spec, points where multithreading is recommended. Anyway... looks like community is OK with the current state and that's more than enough. Good to see interest, anyways. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
Libuv and browsers use it. But no pool is exposed by API to JS. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
Again, async B example is possible and is the proposed. Workers and SharedArrayBuffers are explicit. I'm proposing a non explicit thread under existing structures. The only explicit I'd insert in my proposal are Atomics (for explicit racing conditions treatments). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
Nop. I'm saying the opposite. It will be mutated and it does not matter. Imagining that last example I gave, if "B" ran in a thread... Nothing would change for the JS developer. "Seamless"... Magik. The case you are issuing is what I called a change in foundations of JS... Making threads declared as in Java... And using volatiles. I hypothesized about it... But the effort would be huge and I won't like to see this war. My proposal is break the single-thread dogma and let async, await, promises and components run multithreaded. Simple, but against the a dogma. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
Bradley, show me an JS example where ownership would be important and I'll call you my guru. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
That's what I'm calling seamless multithreading. The only change is the spec change of JS being strictly single-threaded. The proposal is to point aspects where JS can introduce seamless threads and become more paired with more mature platforms. Async, Await, I'd add XHR and any other component with a callback, streams (as it is in Node.js), Promise resolutions and maybe events. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
> The main thread has all ownership. Not explicit, not important. I changed the outer scope the same way and a will last with the outer scope the same way. If "b" ran in a thread... what would change for the JS dev? Nothing. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
> there are additional checks for scoping to prevent escape from isolation
that would be needed as well.. not to mention being able to call other
functions, similarly isolated - Michael
Yes. Expected. And where is the problem? You already have async await
inside async await. What would change?
You already share variables and all the outer scope stuff.
There's not a problem with frozen object in workers. But the proposal is
for multithreading, very different from worker. A worker could be run in a
process for workers, as it happens in some implementations. A thread is a
thread. Is directly connected with the process idea originated from POSIX.
And another facade, worker requires an separate script or dynamic eval.
This is not maintanance friendly.
Bradley... ownership in JavaScript? Ownership in Rust is applicable...
every let in Rust, without mutation explicitation, requires ownership.
JavaScript is the total opposite.
Why would you want ownership today with multithreading if you don't have it
with single thread?
Ex:
(function outer() {
let a = 1;
let b = async function() {
a = 2
}
await b()
console.log(a === 2) -> true
})()
Where is your ownership?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
Bradley, understood. And what in this algorithm would prevent it from being run in another thread with this same seamless code? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
Michael... Object.freeze(). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
The problems you are seeing are not in my idea. They are JavaScript problems I don't want to solve and shall not solve to have what I propose. The only change for those using async await and promises would be changing platform version. Internally, these things would be just moved from Event Loop for a thread and you would not notice. I've additionally started a proposition for explicit calls, but that is an extra and not the core objective. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
> XHR is very different since it does not attempt to change state between threads in a racey fashion. Are you sure? It changes DOM all the time, people does it in almost every callback. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
In JS, if you assign a string to a var containing an object... it will
become an object.
Michael, I'm sorry to say JavaScript is not "safe". Try
Java/Haskell/Fortran.
JavaScript is the land of pragmatic algorithms and "for internals and
abstracted away from you in a safe way".
Workers are cool. I like it.
But for those who knows internals, it is very very expensive. And messaging
with one worker is easy peasy. Try with 5. That amazing onmessages
everywhere without a good organization and you will reclaim your Visual
Studio in no time.
I'm talking about do a single
async rasterizeTheWholeGameStuff() {}
And all the stuff, as a simple async or callback, run inside a green thread.
Is that really so much? I don't think so.
I think all of your statements against it, till now, are not considering
about being "seamless".
Bösch, I think greenlets is a great example... but I'd take it in a second
step, thinking about that additionals I put above.
They can't even agree with an existing, full of racing condition and no
atomicity clojured function body, to be run SEAMLESS in another thread.
Maybe if I create an e-mail like g...@gmail.com or michiok...@gmail.com...
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
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. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
Is not a matter of being faster. Is a matter of using machine potential and using better internal instructions. JavaScript sits over libuv and engines with multithreading without using multithreading. And about being faster, any serious language has a simple feature like threads and Visual Basic should not emerge even in Microsoft specs discussions. What comes next? PHP? I still don't understand why you talk so much about racing conditions in a language which one of the main aspects is loose clojuring and racing condition. Who cares about thread-safety if it were never expected and if it all can be seamless. And where it would not be explicit? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
Bradley, JIT can take care of it. If too hard... "volatile" reserved word is around since the early 00's. *Leo Dutra, **on **Facebook <http://www.facebook.com/leodutra.br> **and LinkedIn <https://www.linkedin.com/in/leobr>* 2016-11-02 13:03 GMT-02:00 Bradley Meck <bradley.m...@gmail.com>: > > > As I said... JS has mutable objects by default. The memory space SHALL > be the same. > > > What is not being covered? Let it come to the surface. > > As stated, that single threaded access to objects and shared memory > multi-threaded access are very different. > > On Wed, Nov 2, 2016 at 9:56 AM, Leo Dutra <leodutra...@gmail.com> wrote: > >> Message passing between two objects is a Law of Nature, broad and >> powerful. >> But there's more than just workers and process spawn in life. >> >> As I said... JS has mutable objects by default. The memory space SHALL be >> the same. >> >> Atomic could handle the racing when needed and a Mutex for locking. >> >> What is not being covered? Let it come to the surface. >> > > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
Bösch, this is the legacy of callbacks. ECMA does a great job with specs, but JS does every step to solve the last step. Callback became a promise for modularity. Promise is hidden in async await for simplicity. Common constructs, but in JS they came in being adapted for JS world. As I said, immutability is not strong in JS as it is not a PURE functional programming language. Weird or not, this led us to the possibility of multithreading with total share and mutability. If we wanna multithread in here, we have to respect all the JavaScript legacy. And the JavaScript legacy hurts Java/C#/whatever feelings cause IT IS DIFFERENT. As said in my first argumentation, we have race condition problems and total share of scope and none died because of it. Multithread can be used to run these callbacks, functions and promises seamlessly and if we want it different... that's a huge bad conversation about foundations of JavaScript and a total change that would wreck the JS world and let us to anything that is not JS. We have to decide if we stick with scope sharing and mutability or look for another language. JS is what it is. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
Message passing between two objects is a Law of Nature, broad and powerful. But there's more than just workers and process spawn in life. As I said... JS has mutable objects by default. The memory space SHALL be the same. Atomic could handle the racing when needed and a Mutex for locking. What is not being covered? Let it come to the surface. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
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...@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...@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.m...@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...@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.m...@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 :
>>&
Re: Proposal of Multithread JavaScript
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...@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.m...@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...@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.m...@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
Re: Proposal of Multithread JavaScript
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.m...@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...@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.m...@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...@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.
>>>>
>
Re: Proposal of Multithread JavaScript
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...@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.m...@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...@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, pu
Re: Proposal of Multithread JavaScript
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.m...@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...@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@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
*TL;DR:*
(function foo() { ... })() // sync and single threaded
(*async *function() { ... })() // async and parallel
Additional:
parallel.run()
parallel.stream()
parallel.sleep()
parallel.waterfall()
...
*Leo Dutra, **on **Facebook <http://www.facebook.com/leodutra.br>
**and LinkedIn
<https://www.linkedin.com/in/leobr>*
2016-11-02 11:38 GMT-02:00 Leo Dutra <leodutra...@gmail.com>:
> 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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Proposal of Multithread JavaScript
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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
