Wednesday, June 6th, 2007

Experimental WorkerPool API

Category: Gears, Google, JavaScript, Library

Aaron Boodman, of Greasemonkey, and now Google Gears fame, has worked on a new abstraction for the WorkerPool API that Google Gears has. The API is in place to enable you to run JavaScript jobs off of the browser thread.

The new abstraction features are:

  • Sets up default error handling for workers
  • Allows workers to depend on external libraries
  • Support for named messages
  • Implement transparent json serialization/deserialization for messages

Here is the new abstraction at work:


  1. function test() {
  2.   var w = new Worker();
  3.   w.load(["fib.js"]);
  4.   w.setMessageHandler("result", function(arg) {
  5.     alert("fib result: " + arg);
  6.   });
  7.   w.onerror = function(msg) {
  8.     alert("fib error: " + msg);
  9.   };
  10.   w.sendMessage("fib", 100);
  11. }

Posted by Dion Almaer at 5:24 am

3.5 rating from 15 votes


Comments feed TrackBack URI

nice,it will be nice if we could just send the worker a function,it should be easy as you can get the code just from doing function.toString().

Comment by uriel katz — June 6, 2007

Could someone give me a real-life scenario of how this would be used?

Comment by Confused — June 6, 2007

Confused: suppose you had a string of SVG path data that you wanted to parse into an array, converting all the curve operations from cubic or whatever they were to quadratic along the way. This could take seconds or more. You would launch a worker process, passing it the path data string, and it would process in parallel to your main GUI, returning the JSON notation of the parsed/converted array when it was done.

The benefit of this is that your UI remains interactive, so you can cancel this processing operation. An additional benefit is that this is true multi-processing, so you could start multiple worker process and have them parsing in parallel, each using a different physical CPU core (if your OS is intelligent about spreading them onto different cores). This would provide a genuine speed-up over a pure in-page javascript solution.

Granted, the bottleneck in AJAX apps is usually not some calculation, but the DOM manipulation or server request delays that become too much, so this doesn’t solve performance in the generic case. Still, it’s nice to have.

Comment by Joeri — June 6, 2007

I’m somewhat confused on this also…

@Joeri: Would this enable multi-threading, or am I totally off on this?

Comment by Frank — June 6, 2007

And can it be modified to not use Google Gears?

Comment by therandthem — June 6, 2007

are they really running on OS level threads (or some similar construct that could throw each one on a seperate core) or are they faked? last i checked, Brendan hated threads and proper multicore/paralellism support wasnt panned untio JS3, which is after ES4 which isnt even implemented yet..

Comment by ix — June 6, 2007

From the google gears page: “The WorkerPool module runs operations in the background, without blocking the UI. Scripts executing in the WorkerPool will not trigger the browser’s “unresponsive script” dialog.”

They place no special demands on the script, except that it can’t communicate with your in-page code except through message passing. This is unlike cooperate multi-threading as often implemented in javascript, where your worker threads must yield periodically to other threads. Since you don’t need to yield in google gears worker threads, for me that means it must be running in an OS-level thread or process, which would imply multi-core support.

Comment by Joeri — June 7, 2007

They are real threads. I think that Brendan doesn’t like the idea of adding multithreading to the JS language (for good reason). Worker doesn’t do that. It’s a background process that you talk to with IPC style messages.

But it is running on a true OS thread, so you get the benetifs of real OS-based multitasking, not janky time sharing setups that are common in JS libraries today.

Comment by Aaron — June 7, 2007

But but, HOW!? I was under the impression that you couldn’t do this in Javascript. Do you need to install something to make this work? I dont get it

Comment by Jonesey — June 7, 2007

> But but, HOW!? I was under the impression that you couldn’t do this
> in Javascript.
You still can’t run multiple threads “in” Javascript. It’s the reason you don’t just pass functions directly (and can’t use free variables / dom nodes) – you’re passing the (completely isolated) code as a string.

> Do you need to install something to make this work?
Yes, Google Gears.

> I dont get it.
Gears has platform-specific native code which implements the 3 supported APIs, those APIs are then provided to you in Javascript.

Don’t worry about things like “but I thought that Mozilla’s JS engine is not re-entrant.”… leave that for Google’s engineers to sort out :-)

Comment by David — July 3, 2007

Leave a comment

You must be logged in to post a comment.