For some subset of use cases I imagine shared-memory multithreading being
limited to immutable objects could do the trick. Of course, I don't know if
real immutability is actually possible in ES as currently specified - if I
called Object.freeze or Object.seal on a JS object would it actually be
safe to pass it to another thread and let both threads use it without any
locking or guards? I imagine there are probably subtle gotchas here where
'read' operations could end up mutating state and causing threads to trip
over each other. Presumably this has already been considered for
transferring objects to web workers as well, i.e. if the object is known
immutable, it can be 'shared' with the worker without a copy.

Combining a graph of immutable objects (like a source AST or scene graph or
something like that) with a transferable arraybuffer would let you tackle
lots of use cases, I think, without as many downsides as true shared-memory
threading. But I don't know if that addresses enough use cases to merit the
effort.


On Sun, Apr 21, 2013 at 10:09 AM, Brendan Eich <brendan at mozilla.com> wrote:

> Domenic Denicola wrote:
>
>> This looks lovely.
>>
>> The only thing I'd want to add: we need integers! And generally better
>> numeric types. From speaking to developers on the ground, this is the
>> biggest missing language feature they see (that isn't already addressed in
>> ES6). I know Brendan has made some moves in this direction in SpiderMonkey,
>> so let's just be sure it doesn't fall off the roadmap :).
>>
>
> Thanks, I bet Mark just forgot value objects are already on the ES7 agenda.
>
>
>  Doing a quick poll of some IRC rooms, there's some call for shared-memory
>> multithreading. I know this was a concern of the asm.js project, or more
>> generally for the JS-as-a-compilation-target mission. I don't think this is
>> a good idea, but just passing it along.
>>
>
> We're researching still and will not let arbitrary data races violate JS
> semantics (for one thing, this would hit all JITs that speculate assuming
> invariants obtained from JS's event-loop concurrency within the same realm,
> er, window -- it would break them all, AFAICT).
>
> It may be that a Parallel JS "patient parent" model where non-overlapping
> slices of an array-buffer are handed off to workers, with results written
> back race-free, is enough for the interesting use-cases.
>
> Wild shared-memory threading with fine-grained coordination? That is an
> anti-pattern in C/C++ due to the high cost of locking or equivalent
> lock-free techniques at scale. In related news, threads still suck.
>
>
>  Finally, I know a lot of people, myself included, are excited about
>> `await` sugar. That is, the plan would be to use generators + promises in
>> ES6 with the awkwardness that entails; once we know what the prevailing
>> patterns are we can eliminate that awkwardness with `await` in ES7. (I've
>> made [a sketch][1] illustrating the idea, but of course the point of
>> waiting is to find something that works, not the first thing I think up.)
>> How this fits in with the concurrency strawman's more ambitious `!`
>> operator is unclear though.
>>
>
> Not everyone is on board for making ! an infix operator via a restricted
> production.
>
> As you say, we still want a clear cowpath to pave for 'await'. This means
> transpiler authors can help.
>
> /be
>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>



-- 
-kg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130421/91fb77f9/attachment.html>

For some subset of use cases I imagine shared-memory multithreading being
limited to immutable objects could do the trick. Of course, I don't know if
real immutability is actually possible in ES as currently specified - if I
called `Object.freeze` or `Object.seal` on a JS object would it actually be
safe to pass it to another thread and let both threads use it without any
locking or guards? I imagine there are probably subtle gotchas here where
'read' operations could end up mutating state and causing threads to trip
over each other. Presumably this has already been considered for
transferring objects to web workers as well, i.e. if the object is known
immutable, it can be 'shared' with the worker without a copy.

Combining a graph of immutable objects (like a source AST or scene graph or
something like that) with a transferable arraybuffer would let you tackle
lots of use cases, I think, without as many downsides as true shared-memory
threading. But I don't know if that addresses enough use cases to merit the
effort.