So I got a chance to review the latest changes (Hurray for the tracking view!: <a href="http://html5.org/tools/web-workers-tracker?from=139&to=140">http://html5.org/tools/web-workers-tracker?from=139&to=140</a>).<div>
<br></div><div>Do we still need the concept of a "protected" worker? We define what a protected worker is, but we don't actually reference that definition anywhere in the spec anymore, since active needed/permissible status is entirely driven by the existence of active/inactive documents.<br>
<div><br></div><div>Overall it looks good, and I think the steps taken to remove GC behavior from the spec will greatly facility implementation. However, I did have a question about the definition of orphaned workers and "active needed" workers:</div>
<div><br></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><span class="Apple-style-span" style="font-family: Helvetica; font-size: 16px; "><span class="Apple-style-span" style="font-size: small;">A worker is said to be an </span><b><span class="Apple-style-span" style="font-size: small;">active needed worker</span></b><span class="Apple-style-span" style="font-size: small;"> if any of the </span><span style="font: 13.0px Courier; color: #e35316"><span class="Apple-style-span" style="font-size: small;">Document</span></span><span class="Apple-style-span" style="font-size: small;"> objects in </span><a href="http://dev.w3.org/html5/workers/#the-worker-s-documents"><span style="text-decoration: underline ; color: #0014c7"><span class="Apple-style-span" style="font-size: small;">the worker's </span></span><span style="font: 13.0px Courier; color: #e35316"><span class="Apple-style-span" style="font-size: small;">Document</span></span><span style="text-decoration: underline ; color: #0014c7"><span class="Apple-style-span" style="font-size: small;">s</span></span></a><span class="Apple-style-span" style="font-size: small;"> are fully active.<br>
</span></span><br><span class="Apple-style-span" style="font-family: Helvetica; font-size: 16px; "><b><span class="Apple-style-span" style="font-size: small;">Closing orphan workers</span></b><span class="Apple-style-span" style="font-size: small;">: Start monitoring the worker such that no sooner than it stops being either an </span><a href="http://dev.w3.org/html5/workers/#active-needed-worker"><span style="text-decoration: underline ; color: #0014c7"><span class="Apple-style-span" style="font-size: small;">active needed worker</span></span></a><span class="Apple-style-span" style="font-size: small;"> or a </span><a href="http://dev.w3.org/html5/workers/#suspendable-worker"><span style="text-decoration: underline ; color: #0014c7"><span class="Apple-style-span" style="font-size: small;">suspendable worker</span></span></a><span class="Apple-style-span" style="font-size: small;">, and no later than it stops being a </span><a href="http://dev.w3.org/html5/workers/#permissible-worker"><span style="text-decoration: underline ; color: #0014c7"><span class="Apple-style-span" style="font-size: small;">permissible worker</span></span></a><span class="Apple-style-span" style="font-size: small;">, </span><i><span class="Apple-style-span" style="font-size: small;">worker global scope</span></i><span class="Apple-style-span" style="font-size: small;">'s </span><a href="http://dev.w3.org/html5/workers/#dom-workerglobalscope-closing"><span style="text-decoration: underline ; color: #0014c7"><span class="Apple-style-span" style="font-size: small;">closing</span></span></a><span class="Apple-style-span" style="font-size: small;"> flag is set to true.</span></span></blockquote>
<div><br></div><div>It sounds like the worker is guaranteed to not be orphaned as long as the parent window is active, even if the user agent is able to identify that the worker is not reachable, which might be a stronger guarantee than was intended. Perhaps the spec already has an implicit assumption that UAs are able to do whatever they want with unreachable items?</div>
<div><br></div><div>-atw</div><div><br><div class="gmail_quote">On Thu, May 28, 2009 at 1:08 PM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch">ian@hixie.ch</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">On Thu, 28 May 2009, Maciej Stachowiak wrote:<br>
><br>
> I'm assuming this is one of the changes:<br>
><br>
> > User agents must either act as if MessagePort objects have a strong<br>
> > reference to their entangled MessagePort object or as if each<br>
> > MessagePort object's owner has a strong reference to the MessagePort<br>
> > object.<br>
><br>
> It seems to me the second alternative prevents MessagePorts created by a<br>
> Window from ever being garbage collected until the user leaves the page.<br>
> Is that a correct understanding?<br>
<br>
</div>Yes.<br>
<div class="im"><br>
<br>
> If so, that seems like it could create unbounded memory leaks in<br>
> long-running Web applications that use MessagePorts, even if all<br>
> references to both endpoints of the MessageChannel are dropped. That<br>
> seems unacceptable to me, unless I misunderstood.<br>
<br>
</div>The requirement is actually indistinguishable from the UA using the other<br>
alternative and just having a really slow garbage collector that only runs<br>
at page-closing time.<br>
<div class="im"><br>
<br>
On Thu, 28 May 2009, Drew Wilson wrote:<br>
><br>
> Is your concern that an ill-behaved app could leak ports (since<br>
> obviously an ill-behaved app could leak ports anyway just by stuffing<br>
> them in some array), or is it that a well-behaved app can't release<br>
> ports? Still need to review the new spec in detail, but from previous<br>
> conversations I'd assumed that calling MessagePort.close() on either end<br>
> would allow the ports to be freed - perhaps we should clarify the<br>
> language in the spec to state that the strong reference is only in place<br>
> for *entangled* ports.<br>
<br>
</div>The UA can at any time switch to the other mechanism, which only has a<br>
strong reference through the entanglement, which basically means that the<br>
UA can be as aggressive as the UA wants to be.<br>
<div><div></div><div class="h5"><br>
--<br>
Ian Hickson               U+1047E                )\._.,--....,'``.    fL<br>
<a href="http://ln.hixie.ch/" target="_blank">http://ln.hixie.ch/</a>       U+263A                /,   _.. \   _\  ;`._ ,.<br>
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'<br>
</div></div></blockquote></div><br></div></div>