<div dir="ltr">On Fri, Apr 12, 2013 at 2:13 PM, Filip Pizlo <span dir="ltr">&lt;<a href="mailto:fpizlo@apple.com" target="_blank">fpizlo@apple.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div>
<div>On Apr 12, 2013, at 1:59 PM, Ryosuke Niwa &lt;<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>&gt; wrote:</div><br><blockquote type="cite"><div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">


<div dir="ltr">On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo<span> </span><span dir="ltr">&lt;<a href="mailto:fpizlo@apple.com" target="_blank">fpizlo@apple.com</a>&gt;</span><span> </span>wrote:<div class="gmail_extra"><div class="gmail_quote">


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div>On Apr 12, 2013, at 1:39 PM, Jarred Nicholls &lt;<a href="mailto:jarred.nicholls@gmail.com" target="_blank">jarred.nicholls@gmail.com</a>&gt; wrote:</div>


<br></div><blockquote type="cite"><div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="ltr"><div>On Fri, Apr 12, 2013 at 2:54 PM, Filip Pizlo<span> </span><span dir="ltr">&lt;<a href="mailto:fpizlo@apple.com" target="_blank">fpizlo@apple.com</a>&gt;</span><span> </span>wrote:</div>


</div></div></blockquote><div><blockquote type="cite"><div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">


<div><br></div><div>For as little worth as it is, I agree with you Filip that providing low-level primitives would be best in terms of a foundation for many parallel programming models.  In terms of actually supporting shared mutable memory and locks, it would be a challenge for the engines to become thread-safe (internally) across contexts that share memory cells.  I&#39;d envision the sharing of mutable memory being an opt-in semantic, marking a piece of memory as being shared/mutable from multiple contexts.</div>


</div></div></div></div></blockquote><div><br></div></div><div>Fixing the engines is a matter of typing. ;-)</div><div><br></div><div>I don&#39;t think we need to add language features for opt-in, though this is an intriguing idea.</div>


<div><br></div><div>Without opt-in, the one biggish challenge would be DOM accesses from threads other than the main thread; I suspect for those the initial implementation would have to throw an exception from non-main-threads if you try to access a DOM node.  This is akin to what some UI toolkits do: they let you have threads but prohibit access UI things from anything but the thread on which the runloop sits.  Of course, they don&#39;t do the thread-check; we would have to do it to preserve integrity and security.</div>


</div></div></blockquote><div><br></div><div>We already have Web workers for this kind of stuff, no?  Is your proposal significantly different from what Web worker offers?</div></div></div></div></div></blockquote></div>

<div>
Web workers don&#39;t have shared memory. They instead have a really expensive message passing model.</div></div></div></blockquote><div><br></div><div>I never thought Web workers was tied to a message passing model but you&#39;ve convinced me of this point in our earlier in-person discussion.</div>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><blockquote type="cite">


<div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>This is just a thought but is it possible to infer semantics of what Web workers and use GPU or SIMD instructions instead of starting a new thread as appropriate?</div>


</div></div></div></div></blockquote><div><br></div></div><div>Probably that would be hard, because the Web Worker semantics are so bizarre: they require copying things all over the place.  It&#39;s probably an even worse match for SIMD/GPU/multicore than just Array.prototype.forEach().</div>


</div></div></blockquote><div><br></div><div>Yeah, I was thinking that this is possible once we&#39;ve added a shared memory model.  You&#39;ve also convinced me in the same in-person discussion and in a reply to Maciej&#39;s response that memory corruption isn&#39;t an issue in JS.  I&#39;m totally with you and Zoltan that the current message passing model makes Web workers pretty much useless.</div>


<div><br></div><div>Perhaps we can come up with some JS API for shared memory &amp; lock and propose it in TC39 or WebApps WG?</div><div><br></div><div>- R. Niwa</div><div><br></div></div></div></div>