[whatwg] Worker lifecycle

[Maciej Stachowiak]

On May 28, 2009, at 10:13 AM, Drew Wilson wrote:

> 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?

The latter.

>  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 conformance requirement I cited is clearly not limited to the case  
where the port is entangled to another port. Unless that clears the  
owner - it didn't seem that was the case in my reading of the spec.

>
> 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).

I'm not sure it is all that unwieldy to keep references to ports you  
are actually using, it seems like many program structures would lead  
to this naturally. However, I would find it sufficient if there were  
some explicit way to say that a port you are using may now be  
collected (such as calling .close() on it).

Regards,
Maciej


>
> -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/c0b55c30/attachment-0002.htm>