Re: [whatwg] Changing postMessage() to allow sending unentangled ports
On Fri, 28 Aug 2009, Drew Wilson wrote: I'm saying that we should differentiate between the closed state and cloned state. Implementors effectively need to do this anyway, because the spec says that closed ports are still task sources, while cloned ports are not. It makes sense to be able to post closed ports via postmessage() because they are still task sources so the recipient could attach an onmessage handler and pull messages off them. It makes no sense to re-send an already-cloned port since it's not a task source and can't ever be a task source again (no way to send messages to it). Likewise it is no longer entangled and so you can't send messages via it. Re-sending a cloned port is an error, and we should treat it as such. I've made the two postMessage() methods that post MessagePort objects throw INVALID_STATE_ERR if any of their ports have already been cloned. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Changing postMessage() to allow sending unentangled ports
On Mon, 17 Aug 2009, Drew Wilson wrote: Following up on this issue: Currently, the checks specified for MessagePort.postMessage() are different from the checks done in window.postMessage() (as described in section 7.2.4 Posting messages with message ports). In particular, step 4 of section 7.2.4 says: If any of the entries in ports are null, *if any of the entries in **ports** are not entangled **MessagePort** objects*, or if any MessagePort object is listed in ports more than once, then throw an INVALID_STATE_ERR exception. It appears that this is fixed. Also, as written, the spec now incorrectly lets us send a cloned port multiple times. So code like this would not generate an error: var channel = new MessageChannel(); otherWindow.postMessage(message1, channel.port1); otherWindow.postMessage(message2, channel.port1); // Sent the same port again That's intentional. By the second call, channel.port1 is not entangled; the 'message2' event will have a lame duck port as its port. The current WebKit behavior is to throw an INVALID_STATE_ERR in this case, while still allowing closed ports to be sent, which I believe is the intended behavior based on previous discussions. If this is correct, we should update the spec to prohibit resending cloned ports. I don't see how this could be correct. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Changing postMessage() to allow sending unentangled ports
I'm saying that we should differentiate between the closed state and cloned state. Implementors effectively need to do this anyway, because the spec says that closed ports are still task sources, while cloned ports are not. It makes sense to be able to post closed ports via postmessage() because they are still task sources so the recipient could attach an onmessage handler and pull messages off them. It makes no sense to re-send an already-cloned port since it's not a task source and can't ever be a task source again (no way to send messages to it). Likewise it is no longer entangled and so you can't send messages via it. Re-sending a cloned port is an error, and we should treat it as such. -atw On Fri, Aug 28, 2009 at 12:11 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 17 Aug 2009, Drew Wilson wrote: Following up on this issue: Currently, the checks specified for MessagePort.postMessage() are different from the checks done in window.postMessage() (as described in section 7.2.4 Posting messages with message ports). In particular, step 4 of section 7.2.4 says: If any of the entries in ports are null, *if any of the entries in **ports** are not entangled **MessagePort** objects*, or if any MessagePort object is listed in ports more than once, then throw an INVALID_STATE_ERR exception. It appears that this is fixed. Also, as written, the spec now incorrectly lets us send a cloned port multiple times. So code like this would not generate an error: var channel = new MessageChannel(); otherWindow.postMessage(message1, channel.port1); otherWindow.postMessage(message2, channel.port1); // Sent the same port again That's intentional. By the second call, channel.port1 is not entangled; the 'message2' event will have a lame duck port as its port. The current WebKit behavior is to throw an INVALID_STATE_ERR in this case, while still allowing closed ports to be sent, which I believe is the intended behavior based on previous discussions. If this is correct, we should update the spec to prohibit resending cloned ports. I don't see how this could be correct. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Changing postMessage() to allow sending unentangled ports
Following up on this issue:
Currently, the checks specified for MessagePort.postMessage() are different
from the checks done in window.postMessage() (as described in section 7.2.4
Posting messages with message ports).
In particular, step 4 of section 7.2.4 says:
If any of the entries in ports are null, *if any of the entries in
**ports** are
not entangled **MessagePort*#1232afb852169a6e_1232af4ce8d86de7_messageport
* objects*, or if any
MessagePort#1232afb852169a6e_1232af4ce8d86de7_messageport object
is listed in ports more than once, then throw an
INVALID_STATE_ERRhttp://infrastructure.html#invalid_state_err
exception.
The spec for MessagePort.postMessage() does not throw an exception if any of
the entries in ports are not entangled (per this thread). We should probably
update the spec for window.postMessage() to define the same behavior there
as well.
Also, as written, the spec now incorrectly lets us send a cloned port
multiple times. So code like this would not generate an error:
var channel = new MessageChannel();
otherWindow.postMessage(message1, channel.port1);
otherWindow.postMessage(message2, channel.port1); // Sent the same port
again
The current WebKit behavior is to throw an INVALID_STATE_ERR in this case,
while still allowing closed ports to be sent, which I believe is the
intended behavior based on previous discussions. If this is correct, we
should update the spec to prohibit resending cloned ports.
-atw
On Thu, Jun 4, 2009 at 10:30 AM, Drew Wilson atwil...@google.com wrote:
Hi all,
I'd like to propose a change to the spec for postMessage(). Currently the
spec reads:
Throws an
INVALID_STATE_ERRhttp://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#invalid_state_err
if
the ports array is not null and it contains either null entries, duplicate
ports, or ports that are not entangled.
I'd like to suggest that we allow sending ports that are not entangled
(i.e. ports that have been closed) - the rationale is two-fold:
1) We removed MessagePort.active because it exposes details about garbage
collection (i.e. an application could determine whether the other side of a
MessagePort was collected or not based on testing the active attribute of
a port). Throwing an exception in postMessage() is the same thing - it
provides details about whether the other end of the port has been collected.
2) Imagine the following scenario: Window W has two workers, A and B.
Worker A wants to send a set of messages to Worker B by queuing those
messages on a MessagePort, then asking Window W to forward that port to
Worker B:
Window W code:
workerA.onmessage(evt) {
if (evt.data == forward) {
// Currently this would throw an exception if the passed port is
closed/unentangled.
workerB.postMessage(messageFromA, evt.ports);
}
}
Worker A code:
function sendMessagesToB() {
var channel = new MessageChannel();
channel.port1.postMessage(message 1);
channel.port1.postMessage(message 2);
channel.port1.postMessage(message 3);
// Send port to worker B via Window W
postMessage(forward, [channel.port2]);
}
Now Worker A is done with its port - it wants to close the port. But it
can't safely do so until it knows that Window W has forwarded the port to
Worker B, so it needs to build in some kind of ack mechanism to know when
it's safe to close the port. Even worse, what if Worker A wants to shut down
- it can't safely shut down until it knows that its message has been
delivered, because the port would get closed when the owner closes.
Since the port still acts as a task source even when it is closed, there
seems to be no reason not to allow passing unentangled ports around - it's a
reasonable way to represent a set of messages. And if you think about it,
there's no reason why this is allowed:
postMessage(msg, port)
port.close()
while this is prohibited:
port.close();
postMessage(msg, port);
Given that in both cases the port will almost certainly be closed before
the message is delivered to the target.
-atw
Re: [whatwg] Changing postMessage() to allow sending unentangled ports
On Thu, 4 Jun 2009, Drew Wilson wrote: I'd like to suggest that we allow sending ports that are not entangled (i.e. ports that have been closed) Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
