postMessage() is currently specified as a synchronous API -- the caller is blocked until the target frame finishes handling the event.<br><br>This seems broken to me.  I would argue this should be an asynchronous API, for two reasons:<br>
<br>1.  <span class="Apple-style-span" style="font-weight: bold;">JS content authors will want an async API.</span>  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:<br>
<br>function messageHandler(messageEvent) {<br> // We assume calling into our complex functions might run out of stack space, so we just handle this in a timeout:<br> setTimeout(0, function() { realMessageHandler(messageEvent) } );<br>
}<br><br>function realMessageHandler(messageEvent) { <br>  // handle the message...<br>  // and, reply to the message<br>  messageEvent.source.postMessage("response message");<br>}<br><br>I forsee JS authors implementing their own asynchronous behavior, as shown above.  Thus defeating reasons for postMessage to be synchronous in the first place.<br>
<br>2.  <span class="Apple-style-span" style="font-weight: bold;">JS engine implementors will want an async API.</span>  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.<br>
<br>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.<br><br>-eric<br><br>