[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