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 <[email protected]> > 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 > > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
