
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 28, 2009, at 10:13 AM, Drew Wilson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">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?</blockquote><div><br></div><div>The latter.</div><br><blockquote type="cite"> 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.</blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div> <br></div><div>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).<br></div></blockquote><div><br></div><div>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).</div><div><br></div><div>Regards,</div><div>Maciej</div><div><br></div><br><blockquote type="cite"><div> <div><br></div><div>-atw</div><div><br><div class="gmail_quote">On Thu, May 28, 2009 at 3:34 AM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"><br> On May 28, 2009, at 2:29 AM, Ian Hickson wrote:<br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> I just checked in a substantial change to the lifetime model for workers.<br> Instead of being bound to their ports, which became especially hard to<br> implement for shared workers, they now just live as long as the Document<br> that created them (all of the Documents that obtained them, for shared<br> workers), with this ownership inheriting to nested workers.<br> <br> I also removed the various ways to observe the lifetime, namely .active<br> and the 'close' events.<br> <br> I hope this will make the shared workers easier to implement. Please let<br> me know if this screws anything up for dedicated workers.<br> </blockquote> <br></div> I'm assuming this is one of the changes:<br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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.<br> </blockquote> <br> 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.<br> <br> Regards,<br><font color="#888888"> Maciej<br> <br> </font></blockquote></div><br></div></div></blockquote></div><br></body></html>