rniwa at webkit.org
Fri Apr 12 22:43:25 PDT 2013
On Fri, Apr 12, 2013 at 2:13 PM, Filip Pizlo <fpizlo at apple.com> wrote:
> On Apr 12, 2013, at 1:59 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo <fpizlo at apple.com> wrote:
>> On Apr 12, 2013, at 1:39 PM, Jarred Nicholls <jarred.nicholls at gmail.com>
>> On Fri, Apr 12, 2013 at 2:54 PM, Filip Pizlo <fpizlo at apple.com> wrote:
>> 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'd
>> envision the sharing of mutable memory being an opt-in semantic, marking a
>> piece of memory as being shared/mutable from multiple contexts.
>> Fixing the engines is a matter of typing. ;-)
>> I don't think we need to add language features for opt-in, though this is
>> an intriguing idea.
>> 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't do the
>> thread-check; we would have to do it to preserve integrity and security.
> We already have Web workers for this kind of stuff, no? Is your proposal
> significantly different from what Web worker offers?
> Web workers don't have shared memory. They instead have a really
> expensive message passing model.
I never thought Web workers was tied to a message passing model but you've
convinced me of this point in our earlier in-person discussion.
> 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?
> Probably that would be hard, because the Web Worker semantics are so
> bizarre: they require copying things all over the place. It's probably an
> even worse match for SIMD/GPU/multicore than just Array.prototype.forEach().
Yeah, I was thinking that this is possible once we've added a shared memory
model. You've also convinced me in the same in-person discussion and in a
reply to Maciej's response that memory corruption isn't an issue in JS.
I'm totally with you and Zoltan that the current message passing model
makes Web workers pretty much useless.
Perhaps we can come up with some JS API for shared memory & lock and
propose it in TC39 or WebApps WG?
- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev