<div class="gmail_quote">(sending from the correct address this time)<br><div><div><div class="h5"><font class="Apple-style-span" face="sans-serif, 'Droid Sans Fallback'"><span class="Apple-style-span" style="line-height: 21px; font-size: medium;"><br>
</span></font><div class="gmail_quote">On Mon, Aug 2, 2010 at 7:57 AM, Jeremy Orlow <span dir="ltr"><<a href="mailto:jorlow@google.com" target="_blank">jorlow@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Tobias Sauerwein</b> <span dir="ltr"><<a href="mailto:tobias.sauerwein@camptocamp.com" target="_blank">tobias.sauerwein@camptocamp.com</a>></span><br>




Date: Tue, Jul 27, 2010 at 8:46 AM<br>Subject: [html5] Web Workers: Race-Condition setting onmessage handler?<br>To: <a href="mailto:help@lists.whatwg.org" target="_blank">help@lists.whatwg.org</a><br><br><br>Hi!<br><br>


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.<br>





<br>I know that there is a message queue [1], but you can easily make up an example where a message is not enqueued:<br><br>Main Script:<br><br><blockquote style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex" class="gmail_quote">





var worker = new Worker("webworker.js");<br>worker.onmessage = function(event) {<br>    console.log('onmessage ' + event.data)    <br>};<br>worker.postMessage("start");<br></blockquote><br><br>





'webworker.js':<br><br><blockquote style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex" class="gmail_quote">setTimeout(<br>    function() {<br>        onmessage = function(event) {<br>





            postMessage("message received");    <br>        };<br>        postMessage("done");<br>    }, 1000);<br></blockquote><br><br>The output is (in Chromium 6.0.475.0 and Firefox 4.01b, Opera 10.70 also outputs "onmessage message received"):<br>





<br><blockquote style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex" class="gmail_quote">onmessage done<br></blockquote><br>So the "onmessage" handler of the web worker is never called.<br>





<br><br>Is this the behavior the specification requests, or is it a bug in Chrome/Chromium and Firefox?<br><br>Tobias<br><br><br><br>[1]: <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#port-message-queue" target="_blank">http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#port-message-queue</a><br>





<br>_______________________________________________<br>
Help mailing list<br>
<a href="mailto:Help@lists.whatwg.org" target="_blank">Help@lists.whatwg.org</a><br>
<a href="http://lists.whatwg.org/listinfo.cgi/help-whatwg.org" target="_blank">http://lists.whatwg.org/listinfo.cgi/help-whatwg.org</a><br>
<br></div><br>
</blockquote></div>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:<div>
<br></div><div><span style="font-family: sans-serif, 'Droid Sans Fallback'; font-size: medium; line-height: 21px; "><span title="jump to a code entry-point" style="border-bottom-style: solid; border-bottom-color: rgb(153, 204, 153); border-bottom-width: initial; ">7. Jump</span> to the <span title="concept-script" style="border-bottom-style: solid; border-bottom-color: rgb(153, 204, 153); border-bottom-width: initial; ">script</span>'s <i>initial code entry-point</i>, and let that run until it either returns, fails to catch an exception, or gets prematurely aborted by the "<a href="http://www.whatwg.org/specs/web-workers/current-work/#kill-a-worker" target="_blank" style="color: rgb(0, 0, 204); background-color: transparent; ">kill a worker</a>" or "<a href="http://www.whatwg.org/specs/web-workers/current-work/#terminate-a-worker" target="_blank" style="color: rgb(0, 0, 204); background-color: transparent; ">terminate a worker</a>" algorithms defined below.<br>
8. If <var title="">worker global scope</var> is actually a <code style="font-size: inherit; font-family: monospace, 'Droid Sans Fallback', sans-serif; font-variant: normal; color: rgb(255, 69, 0); "><a href="http://www.whatwg.org/specs/web-workers/current-work/#dedicatedworkerglobalscope" target="_blank" style="color: inherit; background-color: transparent; ">DedicatedWorkerGlobalScope</a></code> object (i.e. the worker is a dedicated worker), then enable the <span style="border-bottom-style: solid; border-bottom-color: rgb(153, 204, 153); border-bottom-width: initial; ">port message queue</span> of the worker's implicit port.</span></div>
<div><span style="font-family: sans-serif, 'Droid Sans Fallback'; font-size: medium; line-height: 21px; "><br></span></div><div><span style="font-family: sans-serif, 'Droid Sans Fallback'; line-height: 21px; ">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.</span></div>
<div><span style="font-family: sans-serif, 'Droid Sans Fallback'; line-height: 21px; "><br></span></div><div><span style="font-family: sans-serif, 'Droid Sans Fallback'; font-size: medium; line-height: 21px; "><span style="font-size: small; ">-atw</span></span></div>
</div></div></div>
</div><br>