[webkit-dev] Parallel JavaScript: Why a separate ParallelArray types

Ryosuke Niwa rniwa at webkit.org
Fri Apr 12 13:59:56 PDT 2013

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>
> wrote:
> 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?

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?

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130412/aeb18603/attachment.html>

More information about the webkit-dev mailing list