Kategoriarkiv: threading

Discovering Web Workers

So I wanted to learn about Web Workers, since they are (as far as I have come to understand) the only real way of running javascript in a separate thread. The following post is my explanation of the concept as I have percieved it at the time of learning.

Note: I wrote this post in the process of learning, meaning I’m not an expert. Don’t take my word as the truth. They’re just my interpretation of what others have said, and my own tests.

Web Workers

Web Workers allows running scripts “in the background”, in a separate thread from that of the user interface, allowing tasks to be performed without disturbing the user experience. Since javascript is a single threaded language, only able to simulate multithreading by using for example yield() or setInterval(), workers might be the only option for running javascript in separate threads. At least as far as I know.

Some things to know about web workers

  • Workers have a high start-up performance cost
  • Each worker instance consume a high amount of memory
  • Workers are not intened to be used in large numbers at the same time

A worker should not be something you call frequently to perform small tasks, since the cost of calling the worker will exceed the benefit of running it in a separate thread.

So when do you use Web Workers then? Well, if you want to run something that has a high performance cost, without interfering with the user experience, web workers can be a viable option. Uses can include for example perform heavy calculations, or having a “listener” for notifications running in the background.

So how do you do it?

Simple example

First of all, I have a simple html page, with a span to post my results, and buttons to start and stop my worker.

Next, I have a javascript file being loaded to the page. This is not my worker, but the script responsible for calling the worker. I call it foreman.js.

The first thing I want to do is to get my resultSpan element to present the results of the workers. I also create a variable for storing my worker object.

Next I create a function for stopping the worker.

Not all browsers support workers, so a function to check for worker support might be a good idea.

And now to the important parts. We want to be able to call our worker, and create a function for doing just that.

The first thing I do is checking if the browser supports workers. If it doesn’t, I can handle it in different ways. This is good if you don’t want your functionality to break due to compatibility issues.

Then I instantiate a new worker object, referencing the worker javascript file. And yes, the worker code needs to be located in a separate file.

Now when we have the worker object, we need to define what will happen when we get a response from it.  Communication between the foreman and worker will be passed through messages, and we need to declare what to do with those messages. The code below shows 2 ways of doing the same thing.

In the code above, we declare that when we recieve a message from the worker, we will get that message and show it in our resultSpan by setting its innerHTML.

We may also want to handle what happens if an error occurs. In addition to the .onmessage event, we can declare the .onerror event for just this reason.

The last thing is to call the worker. This is done by calling the postMessage function of the worker object.

What will happen now is that the worker javascript will be loaded and executed. The results will depend on what we put in the worker.js file. All we have done in foreman.js is to say that we will present the results of the worker. So let’s take a look at the actual worker: worker.js.

In this simple example, all I want to do is to illustrate a continuous process being run in the background. The worker runs a recursive function every 500 milliseconds and sends the response back to the foreman. The message is being passed by calling the postMessage function. The object put as a parameter in postMessage will be available in event.data in the foreman script. In this case it’s an integer, but it could just as well be a string or JSON object.

Calling specific worker functions

You cannot call a specific function within a worker directly. When the worker is called, it simply runs the file. However, you can implement your own handling by passing function names as parameters.

In my next example, I have another worker file, skilledWorker.js. It contains three functions. I choose to store these in an object called actions, and you will see why later. This is not required however, and there are many ways of implementing support for calling certain functions.

Next, I need to declare what will happen when my worker receives a message.

This says that I should call the function handleMessage and pass my event whenever a message is received. All that’s left is implementing the handleMessage function.

What happens here is that we retrieve the event.data, and get two properties from it, command and parameters. These has to be passed when calling the worker, and I will show how in a bit.

The next piece of code I got a little help from my friend and colleague Anatoly Mironov who has one of the best SharePoint blogs out there.

Since we store our functions in the object called actions, calling “actions[command]” will return the function matching the command string. If no functions matches, the value will simply be undefined. The simple if-statement allows you to check and handle what happens when trying to call a function that doesn’t exist.

The last thing we need to do is to call the worker passing the correct command and parameters.

Passing parameters

Calling a worker with parameters is still done with postMessage(). You can pass either a string or a JSON object. This example will demonstrate how to pass a JSON object. Passed parameters will be available in the worker in event.data. As you saw above, our workers handleMessage function needed the data to contain .command and .parameters. So when calling postMessage() we simply input a JSON object containing these two values.

In the code above, each  line will call the worker, but running different functions, which in turn use different parameters.

In conclusion

Web workers are not very difficult to work with once you understand how they work, and while their use might be limited due to the heavy initial performance cost, being able to running a background thread for large tasks can be quite powerful.

If you want to check the full code I have a GitHub repository for it here: https://github.com/Johesmil/webworkers.

If you want to learn more about Web Workers from people who actually know what they’re talking about, check out the links below. =)

Sources

Web Workers

http://www.htmlgoodies.com/html5/tutorials/introducing-html-5-web-workers-bringing-multi-threading-to-javascript.html
http://www.w3schools.com/html/html5_webworkers.asp
https://developer.mozilla.org/en-US/docs/Web/Guide/Performance/Using_web_workers
http://anders.janmyr.com/2013/02/web-workers.html
http://www.html5rocks.com/en/tutorials/workers/basics/