[whatwg] Worker lifecycle

[Maciej Stachowiak]

On May 29, 2009, at 11:29 AM, Drew Wilson wrote:

>
>
> On Thu, May 28, 2009 at 7:47 PM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
>
> On May 28, 2009, at 5:17 PM, Ian Hickson wrote:
>
> On Thu, 28 May 2009, Maciej Stachowiak wrote:
> On May 28, 2009, at 1:08 PM, Ian Hickson wrote:
> On Thu, 28 May 2009, Maciej Stachowiak wrote:
>
> 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.
>
> The requirement is actually indistinguishable from the UA using the
> other alternative and just having a really slow garbage collector that
> only runs at page-closing time.
>
> So it's exactly equivalent to the old requirement, except the spec now
> specifically points out that you can just leak forever instead. I  
> don't
> think that addresses the original concern at all.
>
> I've tweaked the text some to make it clear that once the port is not
> entangled, it doesn't continue being protected in this way.
>
> The new text seems to be this:
>
> "When a MessagePort object is entangled, user agents must either act  
> as if the object has a strong reference to its entangledMessagePort  
> object, or as if the MessagePort object's owner has a strong  
> reference to the MessagePort object"
>
> It seems to me this allows the following case: two message ports A  
> and B are entangled. A is treated as having a strong reference to B,  
> but is not treated as if its owner has a strong reference to it.  
> However, B is not treated as having a strong reference to A, but is  
> treated as if its owner has a strong reference to it. Is that  
> intended? I think this behavior would be practically implementable  
> and quite useful in many cases, even though it is asymmetric. But I  
> am not sure if the text intended to allow it.
>
> Can you elaborate on this a bit? Where would this asymmetric  
> behavior be useful? It seems like in the specific case you cite, B  
> would be doubly-referenced, while A would be unreferenced.

Ian clarified on IRC that he didn't mean to allow it. The reason it  
would be useful is that it would allow A to be garbage collected as  
soon as it has no references, at which point it can notify B that it's  
gone, and then B can switch rules, and itself be garbage collected  
once it has no references. It would prevent memory leaks but would not  
provide meaningful limits on nondeterminism.

Regards,
Maciej

P.S. In case anyone doubts that distributed GC is hard (as apparently  
Ian did until yesterday), here is a clarifying example. It might seem  
simple to come up with a protocol for two MessagePorts to tell each  
other when they are otherwise unreferenced by anything in their own  
heap with minimal GC hooks. But suppose you have Workers A and B, and  
Window W, and a MessageChannel connecting each pair. The MessagePorts  
are AB-A (the endpoint of the AB channel in A), AB-B, AW-A, AW-W, BW- 
B, BW-W. Now suppose that the two MessagePorts in each global context  
indirectly reference each other (so AB-A has a reference to AW-W and  
vice vera and so forth). It's quite hard to come up with a protocol  
that will let all six MessagePorts know that they have no references  
besides each other and thus may be garbage collected. Note that this  
example can easily arise in practice, for example if the onmessage  
listeners for each message port are closures with both the relevant  
ports in scope. Note also that distributed GC among 3 heaps is still a  
much simpler special case than the fully general case of N heaps. In  
practice, this means that any implementation with split heaps (which  
likely will include all multiprocess implementations) has to take the  
more conservative lifetime rule, tying to the owner. So in practice,  
the only way to reliably free the resources associated with a  
MessagePort will be to .close() it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090529/3f9ad79a/attachment.htm>