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 <[email protected]>
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
