On Thu, 28 May 2009, Maciej Stachowiak wrote:
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
On Thu, May 28, 2009 at 7:47 PM, Maciej Stachowiak m...@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
On May 29, 2009, at 11:29 AM, Drew Wilson wrote:
On Thu, May 28, 2009 at 7:47 PM, Maciej Stachowiak m...@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,
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
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
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
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
So I got a chance to review the latest changes (Hurray for the tracking
view!: http://html5.org/tools/web-workers-tracker?from=139to=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
On Thu, 28 May 2009, Drew Wilson wrote:
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
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
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.
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
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
OK, here's a more focused question - let's imagine that one is implementing
SharedWorkers in a new browser. One seemingly reasonable way to proceed
would be to have a Worker stay alive as long as there are *any* reachable
entangled ports between any window and that worker. Does this cause some
Hi all,
A couple of quick questions about the lifecycle of workers - specifically
I'm trying to grok the body of text at section 4.5 of the Web Workers spec.
It seems like it's saying that if I create a shared worker, then hand off
its port to another window, that shared worker will be orphaned
15 matches
Mail list logo