[whatwg] Possible bug in the way the spec about worker GC behavior
Andrew Wilson
atwilson at google.com
Thu Oct 10 09:54:19 PDT 2013
On Thu, Oct 10, 2013 at 5:06 PM, Ehsan Akhgari <ehsan at mozilla.com> wrote:
> On Thu, Oct 10, 2013 at 7:58 AM, Andrew Wilson <atwilson at 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 at 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/>
>>>
>>
>>
>
More information about the whatwg
mailing list