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.



_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to