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

[Ryosuke Niwa]

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>