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

Rik Cabanier cabanier at gmail.com
Fri Apr 12 21:46:58 PDT 2013

On Fri, Apr 12, 2013 at 9:39 PM, Zoltan Herczeg <zherczeg at webkit.org> wrote:

> > A message passing model a la Web Workers has some advantages compared to
> > threads with shared mutable state and locks:
> > - No possibility of deadlock
> > - No possibility of corrupting data structures due to races
> > - No performance penalty from correctly supporting fine-grained
> concurrent
> > access to arbitrary mutable objects
> >
> > The first is particularly important as you really do not want the web
> > page's UI thread to lock up, even if the page itself is not making
> > progress.
> >
> > I believe message passing as a concurrent programming model is much less
> > prone to severe errors than shared mutable state + locking. I think you
> > have to be super smart to even have a chance of using shared mutable
> state
> > correctly. That being said, I am not sure Web Workers as they exist today
> > are the best possible form of message passing.
> We tried to use WebWorkers for parallel computation, but in their current
> form, they are useless. We also searched for other Worker demos on the
> net, and all of them were slower with workers. I suspect ParallelArray
> will not help either.

Have you tried pdf.js? That uses workers for various operations.
There's an option to turn off workers and it makes pages display slower.

> The problem is not producing messages, but receiving and processing them
> on the other side. Why? Because that involves JS. Noone will use JS to
> search prime numbers, they want to control the UI (animations, image
> generation, physics, etc.).
> Imho Workers need an API, which can be used to set (and perhaps get)
> properties without calling JS. Especially timed set (the change should be
> happen in a given time in the future). Very important for smooth
> animations. These properties must be constants: numbers, strings, RGBA
> arrays, etc. When we set dozens of properties, the extra cost on the UI
> side should be minimal.

What do you mean here? Maybe some pseudocode will make it clear for me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130412/6929319f/attachment.html>

More information about the webkit-dev mailing list