BANGALORE, INDIA: JavaScript has always been a language which is more widely used but very less documented or updated. But with Web Workers, developers can build more responsive and highly interactive browser based applications in JavaScript. Workers add the power of threading in JavaScript which is undoubtedly a big boon to browser applications. Workers provide a way through which a script can be run in background process. An analogy can be a thread of a process, in which the main process gets divided into small threads. Web workers were introduced in Firefox 3.5's JavaScript engine.

It allows you to have multiple threads in JavaScript wherein you can perform various tasks without having to interrupt the user browsing the webpage. Workers can perform the following task; perform any JavaScript tasks without interrupting user interface, perform I/O using XMLHttpRequest (however, the responseXML and channel attributes are always null) , can create sub-workers as long as those workers are hosted within the same origin as the parent page (sub-workers URIs are relative to the parent worker location) and can use timeouts and intervals.

While workers can perform the above tasks very flawlessly, one thing which it can't do is manipulating DOM directly. That means for making changes to the DOM, the worker has to return message to its creator process which in turn will perform the required changes. This is so very true for any background thread(s) in general programming scenario.

Thread Safety

When we talk about creating separate threads in the process, then comes the problem of thread concurrency. Worker interface spawns OS-level threads, which mean we have to be careful while writing code with workers. However in case of “Web workers” in Firefox these problems have been taken care of, so that it is really hard to cause such concurrency problem. A clear example to this can be that there is no direct access to non-thread safe components like DOM.

Web Worker event and methods

Events
onmessage: this event will be raised when a message is posted from or to the worker.

onerror: this event will be raised when an error occurred in the worker.

Methods
postMessage: this method is used to send a message from or to the worker.

terminate: kills the worker immediately without waiting it to finish its task. close: similar to terminate method but is used from within the worker itself.

Spawning a worker

It is straight forward to use a worker. All we need to do is call the Worker() constructor which takes a string parameter of the URI of the script to be executed. By setting the onmessage property with a appropriate function we can receive the message from the worker. Here is a simple example on how to  spawn a worker:

var myWorker = new Worker('my_worker.js');

myWorker.onmessage = function(event)

{

alert("Called back by the worker!\n");

};

Terminating a worker

Terminating or killing a worker is again very simple. By calling worker's method terminate() the running worker will stop immediately without finishing its current operation.  However if you want to kill a worker from within, then you need to use close() method instead of terminate(). Here is a a simple example on how to terminate a worker.

myWorker.terminate();

Error Handling

A script without error handling is considered incomplete; hence we need to have error handling in workers as well. When an error is encountered at runtime, onerror event handler is called. It receives an event called error which helps in controlling the current error. If the worker calls the preventDefault() method , it prevents the default action to take place.