ChromeWorker

Non-standard
This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.

Summary

If you're developing privileged code, and would like to create a worker that can use js-ctypes to perform calls to native code, you can do so by using ChromeWorker instead of the standard Worker object. It works exactly like a standard Worker, except that it has access to js-ctypes via a global ctypes object available in the global scope of the worker. Examples of ChromeWorker's using js-ctypes are availabe on Github and are linked to from the See Also section below. To use a postMessage with callback version of ChromeWorker that features promises, see PromiseWorker.

Addons must use absolute URLs to load their workers, and those URLs have to be using a chrome:// or resource:// protocol (file:// is not accepted.) Addons that wish to use file:// URLs must first register a resource replacement path, using code like this:

var fileuri = Services.io.newFileURI(file);
Services.io.getProtocolHandler("resource").
              QueryInterface(Ci.nsIResProtocolHandler).
              setSubstitution("my-cool-addon", fileuri);
  var worker = new Worker("resource://my-cool-addon/worker.js");

More references:

You can use ChromeWorker from JavaScript code modules. See Using workers in JavaScript code modules for details.
You can use ChromeWorker modules in ChromeWorkers.
See Using web workers for examples and details.

Using XPCOM from chrome workers

Obsolete since Gecko 8.0 (Firefox 8.0 / Thunderbird 8.0 / SeaMonkey 2.5)
This feature is obsolete. Although it may still work in some browsers, its use is discouraged since it could be removed at any time. Try to avoid using it.

Note: Support for using XPCOM and XPConnect from ChromeWorkers was removed in Gecko 8.0 when workers were updated to run in their own operating system level threads, with one thread per worker. See bug 649537 for details.

Prior to Gecko 8.0 (Firefox 8.0 / Thunderbird 8.0 / SeaMonkey 2.5), you could use the Worker postMessage() method to send XPCWrappedNative objects to chrome workers, as long as the underlying object is marked with the nsIClassInfo.THREADSAFE flag, which indicates that the object is safe to access from multiple threads at once.

In addition, ChromeWorker objects have access to a new global XPCOM object -- which is only available to chrome workers -- which has two methods:

createInstance(): Creates an instance of an XPCOM interface. Accepts a single parameter: the contract ID of the interface to create an instance of.
getService(): Returns the shared global service object for the specified XPCOM interface. Accepts a single parameter: the contract ID of the interface to which you wish to obtain a reference.

Using the XPCOM object

Before using the XPCOM object to create instances or access services, it's important to note that this only works with components that are thread safe; if you try to do so with a component that isn't thread safe, an exception will be thrown.

Creating instances of components

If your worker wants to create a thread pool in which it can create additional threads, you can do this:

let myThreadPool = XPCOM.createInstance("@mozilla.org/thread-pool;1");
myThreadPool.threadLimit = 6;
/* send some events with the pool */
myThreadPool.shutdown();

Passing objects to chrome workers

Thread safe objects can be passed to chrome workers using the postMessage() method. Attempting to pass a non-thread safe object will throw an exception.

/* create a new thread, then pass it to the worker */

var thread = Components.classes["@mozilla.org/thread-manager;1"].getService().newThread(0);
worker.postMessage(thread);