On Nov 30, 2009, at 5:09 PM, Maciej Stachowiak wrote:


On Nov 30, 2009, at 4:35 PM, Jeremy Orlow wrote:


To be fair, app developers in general want to do everything synchronously but we (in standards land) have pushed back very hard because software research has shown that such interfaces are very difficult (if not impossible) to parallelize. That's why SharedScript sidesteps the issue by saying there should be no parallelism. Which really is a step backwards.

Now that I've heard more about it, it seems like SharedScript gives the worst of both worlds by encouraging synchronous coding but potentially still resulting in unexpected parallelism. It seems like for correctness you'd have to write nearly the exact same multiple- instance anti-collision code in your SharedScript that you would in each main document if you didn't have SharedScript.

By the way, we could enable the SharedScript programming model at much lower WebKit-level implementation cost and with much less API surface as follows:

- Allow Window to be passed via the structured clone algorithm over a MessageChannel, but it throws on all access if the recipient is not same-origin, in the same thread, and eligible for synchronous calls (i.e. in the same process).

I believe this would allow SharedScript to be implemented in JavaScript. Essentially you'd use a SharedWorker to coordinate and elect a leader Window within each same-process group, which could then create a JavaScript object which it vends to all other Windows. The object does not get GC'd until all the referencing windows go away.

Regards,
Maciej

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to