[whatwg] Worker lifecycle

[Drew Wilson]

So I got a chance to review the latest changes (Hurray for the tracking
view!: http://html5.org/tools/web-workers-tracker?from=139&to=140).
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.

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:

A worker is said to be an *active needed worker* if any of the
Documentobjects in the
worker's Documents
<http://dev.w3.org/html5/workers/#the-worker-s-documents>are fully
active.

*Closing orphan workers*: Start monitoring the worker such that no sooner
than it stops being either an active needed
worker<http://dev.w3.org/html5/workers/#active-needed-worker>or a
suspendable
worker <http://dev.w3.org/html5/workers/#suspendable-worker>, and no later
than it stops being a permissible
worker<http://dev.w3.org/html5/workers/#permissible-worker>,
*worker global scope*'s
closing<http://dev.w3.org/html5/workers/#dom-workerglobalscope-closing>flag
is set to true.


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?

-atw

On Thu, May 28, 2009 at 1:08 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 28 May 2009, Maciej Stachowiak wrote:
> >
> > 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?
>
> Yes.
>
>
> > 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.
>
>
> On Thu, 28 May 2009, 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? 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 UA can at any time switch to the other mechanism, which only has a
> strong reference through the entanglement, which basically means that the
> UA can be as aggressive as the UA wants to be.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090528/7e05a4cc/attachment-0001.htm>