HTML and CSS Reference
In-Depth Information
As you can see, before the Start Work button is clicked, the thread counts for two instances of
Chrome.exe
are 29 (main process) and 6 (a single tab), respectively. When the Start Work button is clicked,
thread utilization changes to 29 and 7, respectively. As you might guess, the thread count increments from
6 to 7 due to the creation of a web worker. When the web worker completes, however, the count doesn't go
back to 6: although the operation has completed, the web worker is still active and will be reclaimed when
the page is closed. If you click the Stop Work button that calls the
terminate()
method, the thread count
goes back to 6 because you're explicitly terminating the thread. If you click the Start Work button multiple
times without first terminating the previous worker thread, the thread count keeps incrementing,
indicating that the previous thread isn't immediately reclaimed by the browser.
n
Note
The previous thread counts (29 and 6) are taken from a sample run of the web form. The values may vary
from browser to browser or even across multiple runs on the same browser. The point is to provide insight as to how
the browser creates and destroys the worker threads.
Using Shared Web Workers
Creating and managing a worker thread is a resource-intensive operation. As you observed in the
preceding section, dedicated web workers are created on per-page basis. If many pages of your web
application need to execute the same script, using dedicated web workers may be costly in terms of thread
utilization and memory. For example, if you open three web pages in three browser tabs, and each creates
a
Worker
object, then three worker threads are created and naturally resource consumption is high. In such
cases, you can use shared web workers, represented by the
SharedWorker
object.
As the name suggests, shared web workers share a worker thread across multiple pages of the web
application. For example, suppose you have three web pages Page1, Page2, and Page3. All of them wish to
execute the same script file,
SharedProcessing.js
. Let's further assume that Page1 is loaded in the browser
and an instance of
SharedWorker
is created for running
SharedProcessing.js
. Later, Page2 is loaded in the
browser and also tries to create an instance of
SharedWorker
to run
SharedProcessing.js
. However,
because Page1 has already created a
SharedWorker
for processing
SharedProcessing.js
, Page2 doesn't
create a new worker thread; instead it uses the same
SharedWorker
created earlier to get the job done. The
same procedure is followed if Page3 is loaded in the browser. A shared web worker is reclaimed only when
all the connections using it are closed.
Although using shared web workers conserves system resources, the downside is that they're slightly
more complex to code than dedicated web workers. To understand how shared web workers are
programmed, let's modify the earlier example to use the
SharedWorker
object.
Listing 10-5 illustrates how a
SharedWorker
object is created in a web form.
Listing 10-5.
Creating a
SharedWorker
Object
<script type="text/javascript">
var worker;
$(document).ready(function () {
$("#btnStart").click(function () {
worker = new SharedWorker("scripts/SharedProcessing.js");
worker.port.addEventListener("message", ReceiveMessageFromWorker, false);
worker.port.start();
worker.port.postMessage("Hello Shared Worker!");
});
});
