10

I'm using web workers to do some CPU intensive work but have the requirement that the worker will respond to messages from the parent script while the worker is still processing.

The worker however will not respond to messages while it is locked in a processing loop, and I have not found a way to say poll the message queue. Thus it seems like the only solution is to break processing at an interval to allow any messages in the queue to be serviced.

The obvious options are to use a timer (say with setInterval) however I have read that the minimum delay between firings is quite long (http://ajaxian.com/archives/settimeout-delay) which is unfortunate as it will slow down processing alot.

What are other peoples thoughts on this? I'm going to try have the worker dispatch onmessage to itself at the end of each onmessage, thus effectively implementing one step of the processing loop per event received from itself, but just wanted to see if anyone had any ideas about this.

Thanks,

Stephen Ierodiaconou
  • 779
  • 1
  • 7
  • 21

3 Answers3

5

A worker can spawn sub workers. You can have your main worker act as your message queue, and when it receives a request for a long running operation, spawn a sub worker to process that data. The sub worker can then send the results back to the main worker to remove the event from the queue and return the results to the main thread. That way your main worker will always be free to listen for new messages and you have complete control over the queue.

--Nick

nciagra
  • 71
  • 4
  • 3
    I think this will not work if the computation must be stopped and resumed. I haven't found a solution for this yet. Example: http://gist.github.com/607058 – Giacomo Oct 01 '10 at 23:50
  • 2
    @nciagra, This answer doesn't work: you had simply pushed the problem one step upwards. So what if you spawn sub workers? Now, those subworkers are busy doing the computation and you can't interrupt them from your mainworker. I guess [the old interval solution](https://stackoverflow.com/a/10180450/632951) (now within the webworker itself) is the only way if we need to interrupt the worker, webworkers seriously need real interrupt mechanism like what Java can do. – Pacerier Jun 20 '17 at 12:59
4

I ran into this issue myself when playing with workers for the first time. I also debated using setInterval, but I felt that this would be a rather hacky approach to the problem (and I had already went this way for my emulated multithreading). Instead, I settled on terminating the workers from the main thread (worker.terminate()) and recreating them if the task that they are involved in needs to be interrupted. Garbage collection etc seemed to be handled in my testing.

If there is data from these tasks that you want to save, you can always post it back to the main thread for storage at regular intervals, and if there is some logic you wish to implement regarding whether they are terminated or not, you can post the relevant data back at regular enough intervals to allow it.

Spawning subworkers would lead to the same set of issues anyway; you'd still have to terminate the subworkers (or create new ones) according to some logic, and I'm not sure it's as well supported (on chrome for example).

James

jsdw
  • 5,424
  • 4
  • 25
  • 29
  • 1
    having the same problem, and used the same solution. Not to loose the calculations made by the webworker I'm posting calculated data at some intervals to the parent "window", and then when respawning the webworker I start with the result calculated so far – Picard Jan 26 '16 at 22:20
  • Unfortunately, worker.terminate() leaks memory... it might work if used sporadically, but in my specific case it hangs the browser very quickly https://bugs.chromium.org/p/chromium/issues/detail?id=502298 – solendil Mar 09 '16 at 14:46
0

Having the same problem I searched the web workers draft and found something in the Processing model section, steps from 9 to 12. As far as I have understood, a worker that starts processing a task will not process another one until the first is completed. So, if you don't care about stopping and resuming a task, nciagra's answer should give better performances than rescheduling each iteration of the task.

Still investigating, though.

Giacomo
  • 11,087
  • 5
  • 25
  • 25