[webkit-dev] SharedWorker design doc

[Drew Wilson]

I followed up with David Levin, who has been working on some chrome-internal
refactoring of the loader code necessitated by the fact that workers in
Chrome run in a different process from the loading frame.
David's take is that long term we'll need to change the loader code so it is
not dependent on a specific frame - his upcoming refactoring may facilitate
this, but there will still be a significant amount of work to achieve this
in WebKit. Over the short term, he suggested that we might be able to
suspend the parent frame, such that it still exists for the purposes of
allowing associated workers to perform network loads, but it itself no
longer has an open window and its active DOM objects are shutdown. When the
last child worker exits, the parent frame can be completely discarded.

I'll need to dig further into this, but I wanted to see whether you thought
this was a reasonable approach and what obstacles there might be to
implementing this.

-atw

2009/4/18 Alexey Proskuryakov <ap at webkit.org>

> Hi Drew,
>
> Thanks for the detailed proposal, it's great to have one.
>
> Prior to diving into threading details, I'd like to clarify a background
> assumption that doesn't seem to be mentioned in the proposal. How does a
> SharedWorker relate to the browsing context that created it? Specifically,
> we probably don't want a SharedWorker to be a top browsing context, because
> that would be an easy way to subvert same origin cookie policy. And since
> loading in WebCore can only happen when there is a Frame, what will happen
> to a SharedWorker whose original frame goes away?
>
>
> 18.04.2009, в 8:55, Drew Wilson написал(а):
>
>  Any feedback would be appreciated, especially for some of the
>> cross-threading and worker lifecycle issues.
>>
>
> - WBR, Alexey Proskuryakov
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090421/91a7b160/attachment.html>