Since JavaScript always runs to completion and blocks the thread it’s running on, there’s never a race condition here. Any message passed from one thread to another is placed in a queue to be run as soon as the target thread is no longer busy.

So in your example, if the worker tries to pass any message back to the main thread it won’t be processed until the main thread has finished running its script, and that means the message handler will already have been set up.

# var myWorker = new Worker(‘my_worker.js’);
# myWorker.onmessage = function(event) {
# print(“Called back by the worker!\n”);
# };

It is unclear when the worker starts, so this looks like a bad example with a race condition.

If worker starts as soon as it is created [1], it looks like there is a race condition between the worker starting and adding the onmessage or onerror handler. If the worker thread signals before the handler is added, then the handler won’t get called. Worse, the behavior will be intermittent, sometimes it may be called and sometimes it won’t, or it may depend on the platform.

Maybe the initial handlers should be provided as parameters to the worker constructor to avoid this race condition (spec bug?).
Maybe the worker should have a separate .start() method so handlers can be initialized before it starts to avoid this race.

[1] http://www.whatwg.org/specs/web-workers/current-work/#worker2