Proposal of Multithread JavaScript

Isiah Meadows isiahmeadows at gmail.com
Fri Nov 4 06:27:31 UTC 2016


Inline.
-----

Isiah Meadows
me at isiahmeadows.com


On Thu, Nov 3, 2016 at 6:41 PM, Michael J. Ryan <tracker1 at gmail.com> wrote:
> Workers define a clear boundary...  In Windows, only the main thread can
> touch the ui..  and in Linux, threads are almost as expensive as
> processes...

That's actually a symptom of Linux having significantly lighter
processes than Windows. Windows keeps the two as completely
independent concepts, and make it rough on the developer if they want
to have inter-process communication, while Linux (and many BSDs) don't
draw such a clear-cut line with processes vs threads. It comes down to
a fundamental difference in approach: Unix derivatives have always
aimed to support multi-*process* applications, while Windows aimed to
support multi-*threaded* ones. (Hence, why Node.js's
`child_process.fork` has always created new processes - it started on
Linux, and processes are almost as cheap as threads.)

>
> Just the same, I'm okay with threads, but feel that not having shared state
> I'd better as you will avoid a large amount of potential bugs.  Having clear
> separation still allows you to solve many problems where threading would
> help in a clean and clear way.
>
> There's been other discussions of a load a threaded module, which could have
> a clear line in the sand.  I wouldn't even mind coroutines or a good, safe
> csp implementation...  However, those lines would take longer to develop
> safely and take longer still to lock down appropriately.
>
> Having worked as threads and allowing a lighter weight message would negate
> a lot of the negatives you mention... It doesn't have to be a serialized
> message.  Adding an immutable object probative would do the trick (given
> fewer hurdles).
>
> All ui/Dom access needs to be serialized anyway, I don't think that's a good
> example of why we absolutely need shared state threads.

I agree that you already have to serialize stuff for the DOM to some
extent, anyways. That's how much of the API works (and it's also how
*not* to design an API).

A good case where high-level shared state would come very handy is
with virtual DOM. If you can offload the backing model to another
thread, you can keep the application even faster, since you can diff
the old DOM while recent UI changes are being processed in another
thread.

But without that ability to share those object instances in a GC-aware
manner and at high frequency, it's rather difficult to do without
generating a *lot* of garbage. As for why a `SharedArrayBuffer` is not
acceptable, it's because there's no way to grow it in place, in case
you have a very large DOM structure.

>
>
> On Nov 3, 2016 12:19 PM, "Leo Dutra" <leodutra.br at gmail.com> wrote:
>>
>> 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 at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


More information about the es-discuss mailing list