[whatwg] Request: window.postMessage should be async

[Eric Seidel]

postMessage() is currently specified as a synchronous API -- the caller is
blocked until the target frame finishes handling the event.

This seems broken to me.  I would argue this should be an asynchronous API,
for two reasons:

1.  JS content authors will want an async API.  Large JavaScript
applications (take GMail for instance) go through contortions today to avoid
hitting the JS stack limit in any browser.  If postMessage is synchronous,
and you receive an event, what is the current stack depth? You have no way
of knowing, and (in the worst case) must assume that the frame you're being
called from already has N-1 frames on the stack, thus you can make no
function calls from within your message handler.  So your message handlers
must always look like this:

function messageHandler(messageEvent) {
// We assume calling into our complex functions might run out of stack
space, so we just handle this in a timeout:
setTimeout(0, function() { realMessageHandler(messageEvent) } );
}

function realMessageHandler(messageEvent) {
 // handle the message...
 // and, reply to the message
 messageEvent.source.postMessage("response message");
}

I forsee JS authors implementing their own asynchronous behavior, as shown
above.  Thus defeating reasons for postMessage to be synchronous in the
first place.

2.  JS engine implementors will want an async API.  Major JS engines, like
SpiderMonkey (Mozilla) and JavaScriptCore (WebKit) can already be used from
multiple threads, but these browsers currently run all JS on the main
thread.  I would rather we didn't prevent FireFox or Safari from some day
running a separate interpreter (and thread) per tab. (Only possible for
frames which are not of the same origin.   Same-origin frames already assume
they can grab at each others innards in a synchronous manner.)  postMessage
imposes a NEW requirement that all connected frames to be run from the same
thread (or somehow synchronize the threads after the first postMessage()
call is made).  This requirement would seem even worse for Microsoft, since
IE8 looks like it's multi-process.  A synchronous postMessage would require
IE8 to keep all frames which have references to each other in the same
process.

Anyway, I'm not the foremost expert here, but I was reading HTML5 last week
and encountered this sync postMessage() requirement, which seemed like a bad
idea.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080404/d86fd7d3/attachment-0001.htm>