[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_ERR<http://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 <atwilson at 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_ERR<http://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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090817/8da93a5b/attachment-0001.htm>

Received on Monday, 17 August 2009 18:02:45 UTC