Web workers

Contents

1. Need for Web Workers

2. Introduction
Types of Web Workers

3. Web Workers API

4. Web-Worker support in browser
“localhost” bug

5. Working of Web Workers
Message Passing Model
Communicating with a Dedicated Web Worker
Communicating with a Shared Web Worker
Example of Dedicated Web Worker
Example of Shared Web Worker
Terminating a worker

6. Error handling and debugging

7. Advantages of using web workers

8. Disadvantages of using web workers

9. Conclusion

10. References

Problems with JavaScript Concurrency

(Need for Web Workers)
JavaScript is a single-threaded environment, meaning multiple scripts
cannot run at the same time. As an example, imagine a site that needs to
handle UI events, query and process large amounts of API data, and
manipulate the DOM. Unfortunately all of that can't be done simultaneous
due to limitations in browsers' JavaScript runtime. Script execution
happens within a single thread. The downside of this is that some CPU
intensive piece of JavaScript can render the page unresponsive or slow it to
a crawl. If the script took long enough, the browser would prompt the user
to see if he/she wanted to stop the unresponsive script.

Unresponsive Script dialog box

Developers implement concurrency by using techniques like setTimeout(),
setInterval(), XMLHttpRequest and event handlers. Though all of these
features run asynchronously but these events are processed after the current
executing script has yielded.

Web Workers – Introduction

The Web Workers specification defines an API for spawning background
scripts in our web application. Web Workers allow us to do things like fire
up long-running scripts to handle computationally intensive tasks, but
without blocking the UI or other scripts to handle user interactions (the
window stays responsive to inputs like clicks and scrolling, even while
processing).

Workers utilize thread-like message passing to achieve
parallelism thus bringing about true multi-threading in
JavaScript.

Types of Web Workers
Dedicated Workers
Shared Workers

The Difference between the two

Dedicated Workers are linked The shared Web Workers are
to the script that created them named so that any script
(called the owner or creator). running in the same
origin/domain can
Dedicated Web Worker is communicate with them,
targeted for applications either by the URL of the
requiring point to point script used to create it, or by
communication. name.

Shared web workers for
communication with multiple
producers and consumers

A Shared Worker exposes
more of the Messaging API
components.

Web Workers API

// Check if Web Workers are supported
if (typeof(Worker) !== "undefined") {
document.getElementById("support").innerHTML =
"Your browser supports HTML5 Web Workers";
}
// Create a new worker
// The URL for the JavaScript file on the same origin
worker = new Worker ("echoWorker.js");
//to load additional JavaScript in the worker
importScripts("helper.js", "anotherHelper.js");

//From the main page
worker.postMessage("Here's a message for we");
//Add event listener
worker.addEventListener("message”, messageHandler,
true);
//Process incoming messages
function messageHandler(e) {
// process message from worker
}
//Handle errors
worker.addEventListener("error", errorHandler, true);
//Stop worker
worker.terminate();

//From the Web Worker
function messageHandler(e) {
postMessage("worker says: " + e.data + " too");
}
//Add event listener
addEventListener("message", messageHandler, true);
//Using a Web Worker within a Web Worker
var subWorker = new Worker("subWorker.js");

Checking Web-Worker support in browser

/* Check if Web Workers are supported */
function getWebWorkerSupport() {
return (typeof(Worker) !== "undefined") ?
true:false;
}

Before we create any web worker related code, we must find out if our
browser supports web-workers.

Currently, Shared web workers are supported in Chrome, Safari and
Opera.

Dedicated Web Workers are implemented by Firefox 3.5, Safari 4 and
Chrome.

Mozilla Firefox 4 does not support shared web workers.

“localhost” bug

When we try to run a Worker script in Chrome on our local machine and not
on a webserver, an error is reported. Workers are restricted by the Same
Origin Policy.

The Same Origin Policy is an important security concept for a number
of browser-side programming languages, such as JavaScript. The
policy permits scripts running on pages originating from the same site
to access each other's methods and properties with no specific
restrictions, but prevents access to most methods and properties across
pages on different sites.

The behavior of same-origin checks and related mechanisms is not well-
defined in a number of corner cases, such as for protocols that do not have a
clearly defined host name or port associated with their URLs (file:, data:,
etc.).

The exact error is:

"Uncaught Error: SECURITY_ERR: DOM
Exception 18". viewing this file in the
file:/// protocol or over http://?
We’ll have to serve the page in order for
security to process it correctly."

Loading a local file, even with a relative URL, is the same as loading a file
with the file: protocol. So the problem is that when we are trying to load the
.js file of worker as a local file - Chrome doesn't like this (for some security
reasons), though we can force the issue by starting Chrome like this:
chrome.exe --allow-file-access-from-files.

Working of Web Workers

Message Passing Model

Page WorkerGlobalScope

onmessage worker.js

postMessaage

Web Messaging Infrastructure

PORT MESSAGING CHANNEL PORT

Messages passed between the main page and workers are copied, not shared. It
appears that the object is being passed directly to the worker even though it's
running in a separate, dedicated space. In actuality, what is happening is that the
object is being serialized as it's handed to the worker, and subsequently, de-
serialized on the other end. The page and worker do not share the same instance, so
the end result is that a duplicate is created on each pass. Most browsers implement
this feature by automatically JSON encoding/decoding the value on either end.

WorkerGlobalScope
Workers have their own JavaScript context, separate from the renderer
Global scope (this) is NOT window
No DOM access
No window
No Document
No cookies
No storage
 Chrome now provides Web Database API
Common Functions (across all implementations)
postMessage
Event support
 addEventListener
 dispatchEvent
 removeEventListener
importScripts
location (read only)
navigator
XMLHttpRequest
setTimeout()/clearTimeout() and setInterval()/clearInterval()

Web Messaging Infrastructure`

Web Messaging more securely enables cross-document communication. Enabling
Cross-site scripting opens a security hole in a browser. For security reasons cross-
site scripting is disabled. Cross-document communication is important to building
Web Applications, so Web Messaging has been architected for security as well as
communication capability.

Web Messaging protocols pass around a MessageEvent object. In the example,
"data" is the attribute containing the message payload; "data" is a string in the
example, but can be any type.

Web Workers leverage the Web Messaging Channel messaging infrastructure. A
MessageChannel connects two MessagePorts. The specification refers to the setup
as "entangling" the ports. A call to postMessage on a MessagePort puts data across
the channel. Each MessagePort maintains a message queue. Messages posted on
one port on the MessageChannel are set to the other port on the MessageChannel
and visa-versa. MessagePorts receive a message via an "onmessage" function.

Web Workers extend the Web Messaging infrastructure supporting posting to an
Array of MessagePorts. MessagePort Arrays are handy for multiple notifications.

Communicating with a dedicated worker
Dedicated workers use MessagePort objects behind the scenes, and thus support all
the same features, such as sending structured data, transferring binary data, and
transferring other ports.
To receive messages from a dedicated worker, use the onmessage event handler
IDL attribute on the Worker object:
worker.onmessage = function (event) { ... };

We can also use the addEventListener() method.

The implicit MessagePort used by dedicated workers has its port message
queue implicitly enabled when it is created, so there is no equivalent to
the MessagePort interface's start() method on the Worker interface.

To send data to a worker, use the postMessage() method. Structured data can be
sent over this communication channel. To send ArrayBuffer objects efficiently (by
transferring them rather than cloning them), list them in an array in the second
argument.
worker.postMessage({
operation: 'find-edges',
input: buffer, // an ArrayBuffer object
threshold: 0.6,
}, [buffer]);

To receive a message inside the worker, the onmessage event handler IDL
attribute is used.
onmessage = function (event) { ... };

We can again also use the addEventListener() method.

In either case, the data is provided in the event object's data attribute.

To send messages back, we again use postMessage(). It supports the structured data
in the same manner.
postMessage(event.data.input, [event.data.input]); //
transfer the buffer back.

Communicating with a shared worker
Shared workers are identified in one of two ways: either by the URL of the script
used to create it, or by explicit name. When created by name, the URL used by the
first page to create the worker with that name is the URL of the script that will be
used for that worker. This allows multiple applications on a domain to all use a
single shared worker to provide a common service, without the applications having
to keep track of a common URL for the script used to provide the service.In either
case, shared workers are scoped by origin. Two different sites using the same
names will not collide.

Creating shared workers is done using the SharedWorker() constructor. This
constructor takes the URL to the script to use for its first argument, and the name
of the worker, if any, as the second argument.
var worker = new SharedWorker('service.js');

Communicating with shared workers is done with explicit MessagePort objects.
The object returned by the SharedWorker() constructor holds a reference to the port
on its port attribute.
worker.port.onmessage = function (event) { ... };
worker.port.postMessage('some message');
worker.port.postMessage({ foo: 'structured', bar:
['data', 'also', 'possible']});

Inside the shared worker, new clients of the worker are announced using
the connect event. The port for the new client is given by the event object's source
attribute.
onconnect = function (event) {
var newPort = event.source;
// set up a listener
newPort.onmessage = function (event) { ... };
// send a message back to the port
newPort.postMessage('ready!'); // can also send
structured data.};

A shared worker will remain active as long as one window has a connection to it.

Example of Dedicated Worker

//The code below will find out the value of pi. It requires looping many, many
times to get at some real accuracy, and that's really processor intensive!. I have not
used web workers here.
<html>
<head>
<script type="text/javascript">
function CalculatePi(){
var loop = document.getElementById("loop");
var c = parseInt(loop.value);
var f = parseFloat(loop.value);
var Pi=0, n=1;
try {
if (isNaN(c) || f != c ) {
throw("errInvalidNumber");
} else if (c<=0) {
throw("errNegativeNumber");
}
for (var i=0;i<=c;i++) {
Pi=Pi+(4/n)-(4/(n+2));
n=n+4; }
document.getElementById("PiValue").innerHTML = Pi;
} catch (e) {
var msg = "Input Error: ";
if (e=="errInvalidNumber")
msg += "Invalid number.";
else if (e=="errNegativeNumber")
msg += "Input must be positive.";
else msg += e.message;
alert(msg);
}}
</script>
</head>
<body>
<label for="loop">Enter the number of cycles:</label>
<input id="loop" type="number" value="100" />
<input type="button" onclick="CalculatePi()"
value="Calculate Pi" />
<br> <br>

<div id="PiValue">PI value appears here</div>
</body>
</html>

We’ll see that for small values of ‘number of cycles’ the user interface will not
block and the value computes within no time but when we enter value in millions
and above, it would do two things: give a fairly accurate value of pi and slow down
the interface to a crawl.

On running the above code for 10000000000 cycles.

//Code with web workers
// pi.htm (main thread)
<html>
<head>
<script type="text/javascript">
function launchPiWebWorker() {
var worker = new Worker('pi.js');

worker.onmessage = function(e) {
document.getElementById("PiValue").innerHTML =
e.data.PiValue;
};
worker.onerror = function(e) {
alert('Error: Line ' + e.lineno + ' in ' +
e.filename + ': ' + e.message);
};

//start the worker
worker.postMessage({'cmd': 'CalculatePi',
'value':
document.getElementById("loop").value
});
}

</script>
</head>
<body>
<label for="loop">Enter the number of cycles:</label>
<input id="loop" type="number" value="100" />
<input type="button" onclick="launchPiWebWorker()"
value="Calculate Pi" />
<br>
<br>
<div id="PiValue">PI value appears here</div>
</body>
</html>

//worker file pi.js

function CalculatePi(loop)
{
var c = parseInt(loop);
var f = parseFloat(loop);
var n=1;

//these errors will need more work…
if (isNaN(c) || f != c ) {
throw("errInvalidNumber");
} else if (c<=0) {
throw("errNegativeNumber");
}

for (var i=0,Pi=0;i<=c;i++) {
Pi=Pi+(4/n)-(4/(n+2));
n=n+4;
}
self.postMessage({'PiValue': Pi});
}
//wait for the start 'CalculatePi' message
//e is the event and e.data contains the JSON object
self.onmessage = function(e) {
CalculatePi(e.data.value);
}

The above code uses a worker to compute the value of pi. This does not block the
user interface as the calculation part is done in a separate thread i.e. in the worker.

This snippet will not run in Chrome if we use the “file://” protocol because of
security reasons in chrome mentioned above in “localhost bug”.

(I have checked this in Chrome version 19.0.1084.52)

Example of a Shared Worker

When we have a web application with multiple windows each needing access to a
worker thread we don't really want to create a new thread in each window because
it takes time and system resources to create each worker thread.

The ability to share a single worker thread among each window from the same
origin comes as a great benefit in this case.
The following is the simplest way to create a SharedWorker thread that multiple
windows from the same origin can make use of:
// Window 1
var aSharedWorker = new SharedWorker("SharedWorker.js");

// Window 2
var aSharedWorker = new SharedWorker("SharedWorker.js");

The SharedWorker object accepts an optional 2nd parameter in the constructor that
serves as the name of the worker.

Most of the time having one shared worker will give the needed functionality. If
we simply have a desire to add more parallel processing, the shared worker can
always spawn web workers of its own.

What if we run into a scenario where we have a need for several windows to share
several workers rather than just the one?

That's where the 2nd parameter of the SharedWorker constructor comes into play.
We can create several different SharedWorker threads by specifying different
names when creating the worker objects.

The following is an example of two windows each sharing two worker threads
'Worker1' and 'Worker2':
// Window 1 - Shared Worker 1 & 2
var aSharedWorker1 = new SharedWorker("SharedWorker.js", "Worker1");


// Window 2 - Shared Worker 1 & 2


Here is a very good example of using shared workers.
http://coolaj86.github.com/html5-shared-web-worker-examples.

NOTE: Shared workers would not work in firefox and in chrome will work only
using http:// protocol.

Terminating the Web Workers

Once the main page starts a Worker thread, the thread doesn’t terminate by
itself. The calling page has to explicitly ask the Worker to terminate. This
may become necessary because creating each new Worker consumes
precious browser resources, which we will need to reclaim once the Workers
task is no longer required.

worker.terminate();

Once a worker is terminated, it goes out of scope and a new worker has to be
created if needed.

close() function can also be used to close the worker from within itself.

self.onmessage = function(e) {
if (e.data == "STOP!") self.close();
};

Error Handling and Debugging
Whenever an uncaught runtime script error occurs in one of the worker's
scripts, if the error did not occur while handling a previous script error, the
user agent must report the error at the URL of the resource that contained the
script, with the position(line number and column number) where the error
occurred, in the origin of the scripts running in the worker, using the
WorkerGlobalScope object’s onerror attribute.

If the implicit port connecting the worker to its Worker object has been
disentangled (i.e. if the parent worker has been terminated), then the user
agent must act as if the Worker object had no error event handler and as if
that worker's onerror attribute was null.
There are some browser differences to note here:

 Chrome 5 and Safari 5 both just pass the error as a string to the error
handler in the thread
 Firefox 3.6.8 and 4.0 beta 2 pass in an ErrorEvent object to the error
handler in the thread.

All browsers (Chrome 5, Safari 5, Firefox 3.6.8 / 4.0 beta 2) implement the
dedicated worker instance error event in the same way by passing in the
ErrorEvent object. When it comes to shared workers, however, the shared
worker object instance cannot trigger the onerror event in Chrome 5 or
Safari 5. It appears that for shared workers the onerror event will only be
triggered for the shared worker instance if there was a network error while
the worker thread was being created.

The following is an example of attaching to the onerror event of a dedicated
worker thread (the example will also work for shared workers with the exception
that with shared workers postMessage needs to be called on a port):

// Attach to the global error handler of the
// thread
onerror = OnErrorHandler;

function OnErrorHandler(e)
{
// In Chrome 5/Safari 5, 'e' is a string for
// both dedicated and shared workers within
// the thread
if (typeof (e) == "string")
{
postMessage("Error Message: " + e);
}
else // Dedicated worker in Firefox...(Firefox
// does not yet support shared workers)
{
postMessage("Error Message: " + e.message + " File
Name: " + e.filename + " Line Number: " + e.lineno);
}
}
// to test the error handler, throw an error
throw "This is a test error";

The message attribute must return the value it was initialized to. When the object is
created, this attribute must be initialized to the empty string. It represents the error
message.

The filename attribute must return the value it was initialized to. When the object
is created, this attribute must be initialized to the empty string. It represents the
absolute URL of the script in which the error originally occurred.

The lineno attribute must return the value it was initialized to. When the object is
created, this attribute must be initialized to zero. It represents the line number
where the error occurred in the script.

Web Workers for which scenarios?

Image processing by using the data extracted from the <canvas> or the
<video> elements. We can divide the image into several zones and push
them to the different Workers that will work in parallel. We’ll then benefit
from the new generation of multi-cores CPUs.

Big amount of data retrieved that we need to parse after an
XMLHTTPRequest call. If the time needed to process this data is important,
we’d better do it in background inside a Web Worker to avoid freezing the
UI Thread. We’ll then keep a reactive application.

Background text analysis: as we have potentially more CPU time available
when using the Web Workers, we can now think about new scenarios in
JavaScript. For instance, we could imagine parsing in real-time what the user
is currently typing without impacting the UI experience. Think about an
application like Word (of our Office Web Apps suite) leveraging such
possibility: background search in dictionaries to help the user while typing,
automatic correction, etc.

Concurrent requests against a local database. IndexDB will allow what
the Local Storage can’t offer us: a thread-safe storage environment for our
Web Workers.

Prefetching and/or caching data for later use

Code syntax highlighting or other real-time text formatting

Background I/O or polling of web services

Processing large arrays or humungous JSON responses

Updating many rows of a local web database

Analyzing video or audio data

Advantages of Web Workers

The Worker interface spawns real OS-level threads, and concurrency can
cause interesting effects in our code if we aren't careful. However, in the
case of web workers, the carefully controlled communication points with
other threads mean that it's actually very hard to cause concurrency
problems. There's no access to non-thread safe components or the DOM and
we have to pass specific data in and out of a thread through serialized
objects.

Web Workers are not ridden with classic concurrency problems such as
deadlocks and race condition

Worker makes a natural sandbox for running untrusted code because it can’t
access page content or cookies.

“Jsandbox is an open source JavaScript sandboxing library that makes use of
HTML5 web workers. Jsandbox makes it possible to run untrusted
JavaScript without having to worry about any potential dangers.

Much of the danger comes from the script being executed on the same origin
– XMLHttpRequest
– OpenDatabase etc.
But new Worker() is same domain only and communication API allows for
cross-origin messaging using postMessage.

Multiple windows (viewers) can be opened that are all viewing the same
item for instance a map. All the windows share the same map information,
with a single worker coordinating all the viewers. Each viewer can move
around independently, but if they set any data on the map, all the viewers are
updated.( This feature of shared web workers can be used in our project )

Disadvantages of using Web Workers

postMessage can transfer strings between threads. But it is very rare that
data requiring analysis is solely string based, mostly we are working with
other primitive types as well such as numbers, Booleans, DateTimes, etc.
and the cost of converting (serializing) strings to/from these data types is
huge.

One thing to be aware of with web workers is that they are not intended to
be used in large numbers and are expected to be long-lived. The worker
threads also have a high start-up performance cost as well as a high memory
cost per worker instance.

Can’t send – Functions:
var func=function(e){return e}
postMessage(func); // Not allowed

Multi-threaded processes are difficult to debug.

Conclusion

As browser-based apps continue to become more complex, and CPUs gain
more cores, there will be a natural need to offload work into separate
threads. HTML5 Web Workers will likely form a big part of this and
combining them with jQuery Deferred objects can make it simpler for
developers to write simple, easy-to-read, parallel code, without adding any
extra overhead.
JavaScript web workers are in their infancy and the use cases are limited.
Browser support varies from patchy to non-existent and debugging is tough.

References

1. http://www.w3.org/TR/workers/
2. http://cggallant.blogspot.in/2010/08/deeper-look-at-html-5-web-
workers.html
3. http://www.html5rocks.com/en/tutorials/workers/basics/

Web workers

More Related Content

What's hot

Viewers also liked

Similar to Web workers

Recently uploaded

Web workers