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.postMessage("Hello Shared Worker!");
Search WWH ::

Custom Search