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

[Drew Wilson]

(sending from the correct address this time)

On Mon, Aug 2, 2010 at 7:57 AM, Jeremy Orlow <jorlow at google.com> wrote:

>
>
> ---------- Forwarded message ----------
> From: Tobias Sauerwein <tobias.sauerwein at camptocamp.com>
> Date: Tue, Jul 27, 2010 at 8:46 AM
> Subject: [html5] Web Workers: Race-Condition setting onmessage handler?
> To: help at lists.whatwg.org
>
>
> Hi!
>
> I am wondering what prevents a web worker from running into race-conditions
> when setting the onmessage handlers. I am worried about that a web worker
> posts a message before the main script has set up the onmessage handler, or
> the other way around, that the web worker posts a message before the main
> script has set up its onmessage handler.
>
> I know that there is a message queue [1], but you can easily make up an
> example where a message is not enqueued:
>
> Main Script:
>
> var worker = new Worker("webworker.js");
>> worker.onmessage = function(event) {
>>     console.log('onmessage ' + event.data)
>> };
>> worker.postMessage("start");
>>
>
>
> 'webworker.js':
>
> setTimeout(
>>     function() {
>>         onmessage = function(event) {
>>             postMessage("message received");
>>         };
>>         postMessage("done");
>>     }, 1000);
>>
>
>
> The output is (in Chromium 6.0.475.0 and Firefox 4.01b, Opera 10.70 also
> outputs "onmessage message received"):
>
> onmessage done
>>
>
> So the "onmessage" handler of the web worker is never called.
>
>
> Is this the behavior the specification requests, or is it a bug in
> Chrome/Chromium and Firefox?
>
> Tobias
>
>
>
> [1]:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#port-message-queue
>
> _______________________________________________
> Help mailing list
> Help at lists.whatwg.org
> http://lists.whatwg.org/listinfo.cgi/help-whatwg.org
>
>
> This is the correct behavior. If there is no onmessage event at the time
that an event arrives at the worker's event loop, it will be dropped on the
floor. The reason this happens is steps 7/8 in section 4.5 of the worker
spec:

7. Jump to the script's *initial code entry-point*, and let that run until
it either returns, fails to catch an exception, or gets prematurely aborted
by the "kill a worker<http://www.whatwg.org/specs/web-workers/current-work/#kill-a-worker>"
or "terminate a
worker<http://www.whatwg.org/specs/web-workers/current-work/#terminate-a-worker>"
algorithms defined below.
8. If worker global scope is actually a
DedicatedWorkerGlobalScope<http://www.whatwg.org/specs/web-workers/current-work/#dedicatedworkerglobalscope>
object
(i.e. the worker is a dedicated worker), then enable the port message queue of
the worker's implicit port.

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). I can't say whether
Opera's behavior is correct or not based on your description - if you
increase the timeout from 1 second to 10 seconds, do you still get the
"onmessage message received"? If so, then that may be a bug in Opera because
events delivered to workers without an onmessage handler set should be
dropped.

-atw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/help-whatwg.org/attachments/20100802/014e0bd4/attachment-0001.htm>