CODEWITHSUNDEEP
javascripthtmlperformancehtml5-canvas
NodeNodeNode
NodeNodeNode

Reputation: 215

How does threading help in using web workers?

I have a general question that I'm having trouble grappling with about web workers. I understand that they engage in background calculations in another thread so they take off the load from the window that the user is in.

However I'm confused on whether that 'other thread' means something like having a different program running on the computer, having a separate browser open, or whether it's like a new tab in the same browser. I feel that this is more of the latter case, but I'm not 100% sure about that and I can't find good explanations.

What implications does this have on the limitations of what we can do with web workers?

Thanks in advance!

Upvotes: 0

Views: 173

Answers (1)

jfriend00
jfriend00

Reputation: 707278

A webworker works like an independent thread of execution. Multiple threads can run at the same time in a computer process. If there are multiple processors, these multiple threads can actually run at the same time. If there is only a single processor, then the OS on the computer handles time slicing between the different threads such that each one runs for a short while, then the next one runs and, to the casual observer, they appear to be running at the sametime.

In a browser, a webworker is indeed a thread of execution that runs independently of the browser window thread (of which there is one for each browser page that is open in the browser). The browser window thread has a number of limititations. The main limitation is that it only processes user events (mouse movement, mouse clicks, keyboard events, etc...) when no javascript code is also running in the main browser thread. So, if you were to run some long running javascript code in the main browser thread, the browser will "appear" to be locked up and won't process any user events while that javascript is running. This is generally considered a bad user experience.

But, if you run this javascript in a webworker, it can go do it's long running thing without blocking the processing of events in the main browser window thread. When it finishes its long running computation, it can then send a message to the main browser window thread and the result can be processed (e.g. displayed in the page or whatever the particular action is).

There are ways to work-around the limitations of the main browser thread by breaking your work into small chunks and executing small chunks of work on a recurring timer. But, using a web worker thread can significantly simplify the programming.

Web workers themselves cannot access the browser page in any way. They can't read values out of it or modify it - they can't run animations, etc... This limits their usefulness a bit to tasks that are more independent from the page. The classic use is some long running calculation (e.g. analyzing data from an image, carrying out ajax calls, doing some complex calculation, etc...). Web workers can communicate with the main thread via a messaging system. It's kind of like leaving a voicemail. The webworker calls up the main thread and leaves a message for it. The next time the main thread has nothing to do, it checks to see if there are any messages from web workers and if so, it processes them. In this way, the main thread and the web worker thread can communicate, but one cannot interrupt the other while it's doing something else.

Upvotes: 3

Related Questions