[webkit-dev] SharedWorkers alternate design
Alexey Proskuryakov
ap at webkit.org
Tue Jun 2 10:50:29 PDT 2009
From Andrew's design document, I don't see how my description was
inaccurate:
---------------------------
Currently, all worker XHR requests are proxied to the parent page and
executed on the main thread. This approach currently works for
dedicated workers because there is a 1:1 mapping between dedicated
workers and active pages, and the worker is shutdown when the page
closes. For SharedWorkers (and for dedicated workers once we introduce
nested workers) this is no longer the case - the worker can outlive
the parent page.
To address this, we will use the DocumentSet for the worker. Worker
XHR requests will still be proxied to the main thread. This task will
request the DocumentSet from the repository, and select a document
from that set to use to satisfy the request. If the DocumentSet is
empty, then it means that the worker is shutting down, so the XHR
should return a failure response.
---------------------------
From my reading of this, it appears that shared workers will use
FrameLoader of the opener page, or some other page in the DocumentSet,
and won't get their own loaders (that would be a feature of persistent
workers, which we aren't even discussing yet). This speaks
specifically about XHR, but I assumed that the same holds true for
other network requests.
- WBR, Alexey Proskuryakov
02.06.2009, в 21:18, Michael Nordman написал(а):
>> When a document calls a SharedWorker constructor, the worker script
>> is loaded from the document's
>> appcache (because all subresource loading goes through appcache, of
>> course).
>
> If I understand correctly, that is not what the spec currently says.
>
> Dedicated workers load as you describe, but not shared workers. The
> algorithm to determine what resource to load for a shared worker is
> the same as the algorithm used to determine what resource to load for
> a window.open(urlToPageWithoutAManifestAttributre) call.
>
> Personally, I think we should defer adding support for the appcache
> scriptable API to workers for the time being. But do support the
> resource loading / cache selection as currently specified. This would
> allow shared workers can be versioned independently (despite not
> having a good reload worker after an update story).
>
> These are shared workers. That implies a degree of separation from the
> pages that are sharing them.
More information about the webkit-dev
mailing list