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