- From: Andrew Wilson <atwilson@google.com>
- Date: Thu, 10 Oct 2013 18:54:19 +0200
- To: Ehsan Akhgari <ehsan@mozilla.com>
- Cc: whatwg <whatwg@lists.whatwg.org>
On Thu, Oct 10, 2013 at 5:06 PM, Ehsan Akhgari <ehsan@mozilla.com> wrote: > On Thu, Oct 10, 2013 at 7:58 AM, Andrew Wilson <atwilson@google.com>wrote: > >> Can you be more specific about what in the spec is incorrect? I guess >> you're saying that Gecko shuts down the worker as soon as the parent >> document is no longer active (when the worker transitions to suspendable), >> so the worker is generally shutdown before the document is discarded? >> > > It's even worse than that, we GC the worker object if we can prove that it > will not have any outstanding work to do in the future. > I suspect that would break in the case of SharedWorkers. If I have a document that creates a shared worker, throws away the reference to the worker, then later that document creates a new SharedWorker object with the same URL, I should get *the same instance of the SharedWorker*, not a new instance. So closing down shared workers just because the owning documents don't currently have an active reference is bad, because it exposes GC specifics. Agreed that the worker lifetime language is complex, but it's complex because it needs to correctly and precisely specify behavior in cases like this. But your described behavior would probably be OK in the case of dedicated workers (where OK = has no visible behavioral difference from a spec-compliant implementation). > > >> I think that behavior is a reasonable interpretation of the spec, and I >> don't think the language you cite implies otherwise - did you want to >> suggest an alternate wording that is clearer? I think implicit in the quote >> you described is that it only applies to workers that are still running, >> not to workers that have previously been shutdown. >> > > Well, removing a document from the worker's list of documents to me > implies that the worker object is not GCed, which implies that UAs cannot > GC worker objects until the document is discarded. This is a bit tied into > the worker lifetime language in the spec, so I don't think that a simple > rewording fixes this, and honestly the worker lifetime prose in the spec is > very difficult to understand. But I'm more interested to know whether I'm > just reading too much into that sentence, or if this is actually what the > spec means to say first. > Again, I think that language is intended to refer only to workers that have not yet been shutdown. Once a worker has been shutdown, it no longer exists from the standpoint of the spec, so "Whenever a Document object is discarded, it must be removed from the list of the worker's Documents of each worker whose list contains that Document" inherently does not include workers that are shut down, because they no longer have a "document list". > > Cheers, > -- > Ehsan > <http://ehsanakhgari.org/> > > > >> >> On Thu, Oct 10, 2013 at 12:12 AM, Ehsan Akhgari <ehsan@mozilla.com>wrote: >> >>> Right now the spec says[1] "Whenever a Document object is discarded, it >>> must be removed from the list of the worker's Documents of each worker >>> whose list contains that Document.". If I'm reading this correctly, this >>> implies that the worker object should be alive by the time that the >>> document gets discarded, which is not what Gecko implements. >>> >>> Should this be fixed in the spec? >>> >>> [1] < >>> >>> http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#the-worker%27s-lifetime >>> > >>> >>> Cheers, >>> -- >>> Ehsan >>> <http://ehsanakhgari.org/> >>> >> >> >
Received on Thursday, 10 October 2013 16:54:43 UTC