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

[Rik Sagar]

Is it therefore correct to say that a Worker thread should not post any
messages from the *initial code*.

Clarify for me, is *initial code* simply *code in the worker script that is
not contained within a function*?


My simplistic example:

**webapp_main.js:**
var w = new Worker("webapp_worker.js");
w.onmessage = function(e){
    window.console.log("WORKER> "+e);
}


**webapp_worker.js**
this.onmessage = function worker_onmessage(){
    postMessage("From onMessage");
}
postMessage("Worker got loaded");



I would expect in this example that the *Worker got loaded*  message should
be dropped on the floor.

Thanks,
Rik.




Rik Sagar, San Jose, CA 95124
Visit : http://sagar.org/


On Mon, Aug 2, 2010 at 10:09 AM, Drew Wilson <atwilson at chromium.org> wrote:

> (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
>
>
> _______________________________________________
> Help mailing list
> Help at lists.whatwg.org
> http://lists.whatwg.org/listinfo.cgi/help-whatwg.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/help-whatwg.org/attachments/20100803/36da366f/attachment-0003.htm>