[webkit-dev] GlobalScript in WebKit

Maciej Stachowiak mjs at apple.com
Mon Nov 30 17:21:34 PST 2009

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.


More information about the webkit-dev mailing list