[webkit-dev] GlobalScript in WebKit
jorlow at chromium.org
Mon Nov 30 17:43:35 PST 2009
On Mon, Nov 30, 2009 at 5:37 PM, Dmitry Titov <dimich at chromium.org> wrote:
> On Mon, Nov 30, 2009 at 5:21 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>> By the way, we could enable the SharedScript programming model at much
>> lower WebKit-level implementation cost and with much less API surface as
>> - 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).
>> Essentially you'd use a SharedWorker to coordinate and elect a leader Window
>> which it vends to all other Windows. The object does not get GC'd until all
>> the referencing windows go away.
> Yep, a variants of this were proposed... One difficulty with this is that
> while JS object is kept alive, the interesting objects like timers, XHR,
> WebSockets die once leader Window is closed.
With the exception of timers, most of these things would also suffer from
network errors. I wonder if the same code could be used to recover from
In addition, everything you mentioned would be a good use case for a
SharedWorker since it'd be fairly detached from UI and is async.
> Plus, the leader [re]election algorithm should be implemented. It is not
> impossible to keep track of enough things to fix up the context, but it is
> way too difficult and error-prone.
> It sounds like by making it easier with SharedScript we'd remove the burden
> of those implementations from many web developers. Just connect to it and it
> provides stable JS context for things to run in.
> If we go with this, I believe we'll need to follow up with things like
> making XHR work even if page created it was closed... It might end up being
> essentially the same as SharedScript itself.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev