web-worker - Dave's Blog

Search

Subtleties of postMessage

2013 Jul 15, 1:00

In IE10 and other new browsers one may create MessageChannel objects that have two MessagePorts each connected (w3c spec calls it entangled) to one another such that postMessage on one port results in the message event firing on the other. You can pass an array of ports as the last parameter to postMessage and they show up in the ports property of the message event arg.

Origin

The postMessage here is like the worker postMessage and unlike the window and iframe postMessage in that it applies no origin checking:

  1. No origin postMessage in workers and MessagePorts: postMessage(messageData, ports)
  2. Origin postMessage in windows and iframes: postMessage(messageData, targetOrigin, ports)

Unfortunately the origin isn't an optional parameter at the end to make the two postMessages have the same signature.

On the event handler side, the event arg always has an origin property. But in the no origin case it is always the empty string.

Source

There is also a source property on the message event arg which if set is an object that has a postMessage property allowing you to post back to your caller. It is set for the origin case, however, in the no origin case this property is null. This is somewhat reasonable because in the case of MessagePort and Workers there are only two endpoints so you always know the source of a message implicitly. Unlike the origin case in which any iframe or window can be calling postMessage on any other iframe or window and the caller is unknown. So not unreasonable but it would be nice if the source property was always set for consistency.

MessageChannel start

When a MessageChannel is created it has two MessagePorts, but until those ports are started they will queue up any messages they receive. Once started they will dispatch all queued messages. Ports don't have to be started to send messages.

A port may be started in two ways, either by explicitly calling the start method on the port, or by setting the onmessage callback property on the port. However, adding an event listener via addEventListener("message", does not start the port. It works this way in IE and Chrome and the spec states this as well.

The justification is that since you can have only one callback via onmessage that once set you must implicitly be ready to receive messages and its fine to start the port. As opposed to the addEventListener in which case the user agent cannot start implicitly because it doesn't know how many event listeners will be added.  I found Hixie stating this justification in geoloc meeting notes.

Links

W3C Spec

Opera introduction

PermalinkCommentsDOM html javascript postMessage technical web-worker worker

Web Worker Initialization Race

2012 Feb 24, 1:44

Elaborating on a previous brief post on the topic of Web Worker initialization race conditions, there's two important points to avoid a race condition when setting up a Worker:

  1. The parent starts the communication posting to the worker.
  2. The worker sets up its message handler in its first synchronous block of execution.

For example the following has no race becaues the spec guarentees that messages posted to a worker during its first synchronous block of execution will be queued and handled after that block. So the worker gets a chance to setup its onmessage handler. No race:

'parent.js':
var worker = new Worker();
worker.postMessage("initialize");

'worker.js':
onmessage = function(e) {
// ...
}

The following has a race because there's no guarentee that the parent's onmessage handler is setup before the worker executes postMessage. Race (violates 1):

'parent.js':
var worker = new Worker();
worker.onmessage = function(e) {
// ...
};

'worker.js':
postMessage("initialize");

The following has a race because the worker has no onmessage handler set in its first synchronous execution block and so the parent's postMessage may be sent before the worker sets its onmessage handler. Race (violates 2):

'parent.js':
var worker = new Worker();
worker.postMessage("initialize");

'worker.js':
setTimeout(
function() {
onmessage = function(e) {
// ...
}
},
0);
PermalinkCommentstechnical programming worker web-worker html script

[html5] Web Workers: Race-Condition setting onmessage handler?

2011 Sep 20, 7:17There's no race between posting to a web worker and the web worker setting up its message handler as long as the web worker sets its message handler in the first sync. block of code that runs in the web worker: "Basically, once the initial worker script returns, the worker's port is enabled and the normal message port event delivery mechanism kicks in (including dropping unhandled messages on the floor)."PermalinkCommentstechnical web-worker webbrowser programming postMessage
Older Entries Creative Commons License Some rights reserved.