[whatwg] Changing postMessage() to allow sending unentangled ports

[Drew Wilson]

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/20090604/8bf93aba/attachment-0002.htm>