On Fri, Apr 12, 2013 at 10:34 PM, Filip Pizlo <fpi...@apple.com> wrote:
> > On Apr 12, 2013, at 9:46 PM, Rik Cabanier <caban...@gmail.com> wrote: > > > > 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. > > > Pdf.js is really cool. But I agree with Zoltan's general assessment of > workers: they are not easy to use. Just because pdf.js uses them doesn't > mean we can't do better. > I completely agree. Not only are they hard; apparently it's unspecified what API's are available to them. [1] I was just replying to his point that all uses of workers make things slower. 1: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Apr/0054.html > >> 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 > > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
