3

I am new to HTML5 Webworker API. A web worker is a JavaScript running in the background, without affecting the performance of the page.

Given below is simple example for Webworker API. If I start the Webworker and don't stop working with other pages and sites. After few minutes my browser will has more load and problem with working with browsers. It is running in background but if we not stop the Webworker, they will increase and affecting the performance issue so, How can I state that "without affecting the performance of the page".

Can anyone give the proper example or sugestion on webwork for actual use and Can We compare the webworker with the Java Multithreading and Linux Process ?

demo.html

<!DOCTYPE html>
<html>
<body>
<p>Count numbers: <output id="result"></output></p>
<button onclick="startWorker()">Start Worker</button> 
<button onclick="stopWorker()">Stop Worker</button>
<script>
    var w;

    function startWorker() {
        if(typeof(Worker)!=="undefined") {
            if(typeof(w)=="undefined") {
                w=new Worker("demo_workers.js");
            }
            w.onmessage = function (event) {
                document.getElementById("result").innerHTML=event.data;
            };
        } else {
            document.getElementById("result").innerHTML="Sorry, your browser does not support Web Workers...";
        }
    }

    function stopWorker() { 
        w.terminate();
    }
</script>
</body>
</html>

demo_workers.js

var i=0;

function timedCount() {
    i=i+1;
    postMessage(i);
    setTimeout("timedCount()",500);
}

timedCount();
Smile
  • 2,770
  • 4
  • 35
  • 57
Ashwin Parmar
  • 3,025
  • 3
  • 26
  • 42

1 Answers1

1

Webworkers don't interrupt the UI thread

Webworkers in javascript give us the ability to spawn new threads. In most browser implementations, javascript is single-threaded. It shares execution time with the UI thread that is responsible for reflowing and repainting the page. If you execute javascript that would normally take a very long time to process, you can easily make your page unresponsive, as it will be busy doing whatever you told it to do instead of handling user events and repainting the page. We can fix this in a number of ways (setTimeout or work queues), but we can also use webworkers if you're trying to calculate the right sort of data.

So, yes spawning more threads will add more load to your computer, but at the same time work done in a webworker won't interrupt the UI thread that is responsible for rendering the page.

Webworker Limitations

Webworkers do spawn real OS-level threads, and as we know web developers can't be trusted to handle this properly, so the API has been bubbled wrapped so we'd have to try very hard to hurt ourselves.

With that in mind:

  • Webworkers don't have access to the DOM
  • They can only communicate via message passing

This limits their usefulness, as you cannot calculate DOM fragments in another thread, and you're adding serialization overhead for all the data you're sending back and forth. So you better be working on an embarrassingly parallel problem, or it probably isn't worth the effort.

In other languages like Java, C, and other concurrency specific languages generally give you much better control over threads. Most mainstream languages use the shared memory model, where you share memory and control its access via mutexes, barriers and other mechanisms. You can, of course, also easily get into trouble if you're not careful, as deadlocks and other concurrency bugs are harder to debug.

Some examples of embarrassingly parallel problems?

An embarrassingly parallel problem would be something that can be easily split up into separate pieces of work that don't require much communication.

For example:

  • Raytracer (You can calculate each pixel without knowing other pixel values)
  • Matrix Multiplication
  • Brute force searches
Kerry Liu
  • 2,072
  • 16
  • 16
  • Webworkers is single threading means at the same time we work with only one instance? And should we go for wobworkers for real-time apps or do ajaxify development is good for now. – Ashwin Parmar Oct 01 '13 at 16:10
  • 1
    @AshwinP you'd probably be more interested in [websockets](http://www.w3.org/TR/websockets/) [link2](https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_client_applications) and services like [firebase](https://www.firebase.com/). I have yet to find a use for webworkers outside of graphic rendering experiments. – Kerry Liu Oct 01 '13 at 16:17
  • Thanks @Kerry Liu. But If we use multiple webworkers on my page it will be very much harmful for my system. right? May be performance Issue. – Ashwin Parmar Oct 04 '13 at 13:50
  • 1
    @AshwinP Using webworkers, like any other threaded program, is only "harmful" if implemented incorrectly, or maliciously. – Kerry Liu Oct 04 '13 at 15:00
  • Sadly not only ""Webworkers don't interrupt the UI thread"", but the UI thread lacks any mechanism to interrupt the worker too. See https://stackoverflow.com/a/32269593/632951 – Pacerier Jun 20 '17 at 12:57