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

[Zoltan Herczeg]

> 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.

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.

Regards,
Zoltan