[whatwg] Worker lifecycle

[Drew Wilson]

Is your concern that an ill-behaved app could leak ports (since obviously an
ill-behaved app could leak ports anyway just by stuffing them in some
array), or is it that a well-behaved app can't release ports? Still need to
review the new spec in detail, but from previous conversations I'd assumed
that calling MessagePort.close() on either end would allow the ports to be
freed - perhaps we should clarify the language in the spec to state that the
strong reference is only in place for *entangled* ports.
The alternative is to force applications to keep explicit references to all
of their ports, which seems unwieldy and also worse given that there's now
no way for applications to determine whether a given port is entangled or
not (since .active exposes the behavior of the garbage collector).

-atw

On Thu, May 28, 2009 at 3:34 AM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On May 28, 2009, at 2:29 AM, Ian Hickson wrote:
>
>
>> I just checked in a substantial change to the lifetime model for workers.
>> Instead of being bound to their ports, which became especially hard to
>> implement for shared workers, they now just live as long as the Document
>> that created them (all of the Documents that obtained them, for shared
>> workers), with this ownership inheriting to nested workers.
>>
>> I also removed the various ways to observe the lifetime, namely .active
>> and the 'close' events.
>>
>> I hope this will make the shared workers easier to implement. Please let
>> me know if this screws anything up for dedicated workers.
>>
>
> I'm assuming this is one of the changes:
>
>  User agents must either act as if MessagePort objects have a strong
>> reference to their entangled MessagePort object or as if each MessagePort
>> object's owner has a strong reference to the MessagePort object.
>>
>
> It seems to me the second alternative prevents MessagePorts created by a
> Window from ever being garbage collected until the user leaves the page. Is
> that a correct understanding? If so, that seems like it could create
> unbounded memory leaks in long-running Web applications that use
> MessagePorts, even if all references to both endpoints of the MessageChannel
> are dropped. That seems unacceptable to me, unless I misunderstood.
>
> Regards,
> Maciej
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090528/bbadc2b4/attachment-0002.htm>