Proposal of Multithread JavaScript

Isiah Meadows isiahmeadows at gmail.com
Thu Nov 3 01:32:25 UTC 2016


And yes, I've been paying attention to safety. What I'm actually going
to be using behind the scenes for the proposal is an event-driven
system to coordinate thread access and having both atomic updates and
synchronized calls by default, and this system will also work with the
event loop as well, with a basic priority system in place.

I'm still working on it, and I plan to have a gist in tandem with
this, so I don't have to have a long, detailed email to start. I just
want to see something a little lighter than just cloning *everything*
(zero copy preferable), and the ability to have high-level
manipulation of shared data without requiring SharedArrayBuffers, a
`malloc` reimplementation, and a boilerplatey abstraction on top of
everything.
-----

Isiah Meadows
me at isiahmeadows.com


On Wed, Nov 2, 2016 at 8:27 PM, Michael J. Ryan <tracker1 at gmail.com> wrote:
> At the module level for a parallel import, etc would be a decent point to
> support parallel execution... But checks would be needed to avoid migration
> at boundaries...
>
> I'm not opposed to parallel execution... But changing the async spec to
> allow unsafe threads is just a really bad idea...  I have also seen many
> bugs in .Net and Java code surrounding bugs and rather not see those types
> of shared/static access in JS.
>
> Having an import worker/parallel with a clean interface could be good...
>
>
> On Nov 2, 2016 1:28 PM, "Isiah Meadows" <isiahmeadows at gmail.com> wrote:
>
> I've been working on another idea for parallelism that also leverage
> modules, but doesn't involve workers. It will enable read-only resource
> sharing of direct object instances across threads, using realms, a built-in
> concept of thread ownership, and atomicity for ensuring thread safety. It
> also allows for blocking calls for individual atomic access.
>
>
> On Wed, Nov 2, 2016, 16:00 Leo Dutra <leodutra.br at gmail.com> wrote:
>>
>> 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 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