I initiated a web worker on chrome and it had a simple function that was called repeatedly using setTimeout. Surprisingly the web worker terminated after the function was called around 1000 times. Can anyone explain why? I guess chrome is doing some optimization.

webworker.js

function hi() {
    postMessage('1');
    setTimeout(hi, 1);
}
hi();

main.js

var blob = new Blob([code]);
var blobURL = window.URL.createObjectURL(blob);
var worker = new Worker(blobURL);
worker.onmessage = function(data) {
    console.log(data.data); // gets called around 1000 times and done
};

EDIT: Reproduced in a fiddle: / It seems to takes arbitrarily long for the onmessage callback to stop firing, as quickly as a few seconds and as long as +5 mins

I initiated a web worker on chrome and it had a simple function that was called repeatedly using setTimeout. Surprisingly the web worker terminated after the function was called around 1000 times. Can anyone explain why? I guess chrome is doing some optimization.

webworker.js

function hi() {
    postMessage('1');
    setTimeout(hi, 1);
}
hi();

main.js

var blob = new Blob([code]);
var blobURL = window.URL.createObjectURL(blob);
var worker = new Worker(blobURL);
worker.onmessage = function(data) {
    console.log(data.data); // gets called around 1000 times and done
};

EDIT: Reproduced in a fiddle: http://jsfiddle/meovfpv3/1/ It seems to takes arbitrarily long for the onmessage callback to stop firing, as quickly as a few seconds and as long as +5 mins

• javascript
• google-chrome
• web
• worker

• Sure we can explain why, but don't ask us to guess it. You'll have to show a minimal verifyable example so we can test it out. – Ismael Miguel Commented May 8, 2016 at 11:47
• @IsmaelMiguel i've updated the question with the worker.js code. Basically I make a blob out of a string and give it to the worker – ffff Commented May 8, 2016 at 11:53
• I am having the same issue. I've found that the Workers don't terminate (tested with a console.log), the onmessage callback just stops being fired at some point. Very strange, and unacceptable browser behaviour! table flip – Anson Kao Commented May 26, 2016 at 4:46
• Maybe the message queue is filling up or something like that? – user663031 Commented May 26, 2016 at 17:50
• 1 or perhaps your workers are being garbage collected, which will happen (I think) if you don't keep references to them around. – user663031 Commented May 26, 2016 at 18:54

3 Answers 3

Here is my best guess at what is happening. By posting a message from the Web Worker every 1ms, you are demanding that the main thread processes each posted message within 1ms.

If the main thread isn't able to process the message within 1ms, you are still sending it a new message even though it isn't finished processing the last message. I would imagine this puts it into a queue of messages waiting to be processed.

Now since you are sending messages from the web worker faster than they can be processed, this queue of unprocessed messages is going to get bigger and bigger. At some point Chrome is going to throw up its hands and say "There are too many messages in the queue", and instead of queueing new messages for processing, it drops them.

This is why if you use a reasonable number in your timeout like 100ms, the message has plenty of time to be processed before the next message is sent, and no problem with unprocessed messages occurs.

I've created a jsFiddle where the worker sends a message to the main thread, and the main thread sends the message back to the worker. If that process doesn't happen before the next message is sent, the counters in both threads will be mismatched and the web worker will terminate.

http://jsfiddle/meovfpv3/3/

You can see that with a reasonable setTimeout of 100ms, all messages have adequate time to process before the next message occurs.

When you lower the setTimeout to 1ms, the message chain doesn't have time to finish before the next message is sent and the counters in each thread bee eventually desynced, tripping the if clause and terminating the web worker.

One way to fix this problem is instead of blindly posting a message every 1ms whether the last one has been processed or not, only post a new message after you have received a message back from the main thread. This means that you are only posting messages as fast as the main thread can process them.

For pleteness here is a copy of the JSFiddle code:

Worker:

  var counter2 = 0;
  var rcvd = true;
  function hi() {
    counter2++;
    console.log("")
    console.log("postMessage", counter2)
    postMessage(counter2);
    if (!rcvd) {
        self.close();
      console.log("No message received");
    }
    rcvd = false;
    setTimeout(hi, 1);
  }
  hi();
  onmessage = function(e) {
    rcvd = true;
    console.log("secondMessage", e.data);
  }

Main:

var ww = document.querySelector('script[type="text/ww"]'),
    code = ww.textContent,
    blob = new Blob([code], {type: 'text/javascript'}),
    blobUrl = URL.createObjectURL(blob),
    worker = new Worker(blobUrl),
    counter = 0;

worker.onmessage = function(e) {
    counter++;
  console.log("onmessage:", counter);
  worker.postMessage(e.data);
}

Firstly, a couple of observations, which I cannot explain but are kind of interesting and might be inspirational for someone:

• @Anson - If I put your jsFiddle code into Codepen (still in Chrome) there are no problems there. The onmessage callback just keeps working!

• And back in jsFiddle... It fails even changing the setTimeout to a long gap like 10s so it's not the number of times that the worker posts a message, it's how long before the onmessage callback stops firing – which has a lot of variance.

Then I found some ways to keep the onmessage handler alive in this specific example:

• Add a button/link in the html and a handler (I used jQuery) that will terminate the worker on click. Just adding this code fixes it. $("#stop").on("click",function(e){e.preventDefault();worker.terminate();});
• Just add console.log(worker) after defining onmessage.
• Inspired by an answer posted in the related question you can also simply add window.worker = worker after defining onmessage.

Something about mentioning worker again in all cases seems to keep it alive.

Are you trying to postMessage every 1ms? Then you probably meant to use setInterval():

setInterval(function(){
    postMessage('1');
}, 1);

Edit: I incorrectly saw recursion which wasn't there, just because I was looking for it. I would still use setInterval over setTimeout though.