On Fri, Apr 12, 2013 at 9:39 PM, Zoltan Herczeg <zherc...@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.
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev