Hi all,<div><br></div><div>I'd like to propose a change to the spec for postMessage(). Currently the spec reads:</div><div><br></div><div><span class="Apple-style-span" style="font-family: -webkit-sans-serif; font-size: 16px; color: rgb(0, 128, 0); line-height: 21px; ">Throws an <code style="font-size: inherit; font-family: monospace; font-variant: normal; color: rgb(255, 69, 0); "><a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#invalid_state_err" style="color: inherit; background-image: initial; background-repeat: initial; background-attachment: initial; -webkit-background-clip: initial; -webkit-background-origin: initial; background-color: transparent; background-position: initial initial; ">INVALID_STATE_ERR</a></code> if the <var title="">ports</var> array is not null and it contains either null entries, duplicate ports, or ports that are not entangled.</span></div>
<div><br></div><div>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:</div><div><br></div><div>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.</div>
<div><br></div><div>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:</div>
<div><br></div><div>Window W code:</div><div><br></div><div>  workerA.onmessage(evt) {</div><div>    if (evt.data == "forward") {</div><div>        // Currently this would throw an exception if the passed port is closed/unentangled.</div>
<div>        workerB.postMessage("messageFromA", evt.ports);</div><div>    }</div><div>  }</div><div><br></div><div>Worker A code:</div><div><br></div><div>function sendMessagesToB() {</div><div>    var channel = new MessageChannel();</div>
<div>    channel.port1.postMessage("message 1");</div><div>    channel.port1.postMessage("message 2");</div><div>    channel.port1.postMessage("message 3");</div><div>    // Send port to worker B via Window W</div>
<div>    postMessage("forward", [channel.port2]);</div><div>}</div><div><br></div><div>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.</div>
<div><br></div><div>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:</div>
<div><br></div><div>postMessage("msg", port)</div><div>port.close()</div><div><br></div><div>while this is prohibited:</div><div><br></div><div>port.close();</div><div>postMessage("msg", port);</div><div>
<br></div><div>Given that in both cases the port will almost certainly be closed before the message is delivered to the target.</div><div><br></div><div>-atw</div><div><br></div><div><br></div><div><br></div>