JavaScript/HandlingThreads

In Firefox 4, JS extensions using nsIThread.dispatch won't work the same way they have in the past. The purpose of this page is to document the design choices we have, so we can get to a decision, late though it may be.

One thing to do no matter what: enforce nsIClassInfo::MAIN_THREAD_ONLY flag in XPConnect, throwing a new error if any main-thread object is accessed by another thread. This would have saved us McAfee Site Advisor, BitDefender, and other add-on topcrashes.

Here are the choices we have. We can pick more than one.

MT Proxies

Disadvantages

Not possible on non-global scope objects, which must be native (Call, Block, DeclEnv)

Env. cloning + global-MT-proxy

Advantages

Source-compatible.

Mostly runtime-compatible -- anything broken was doing something unsafe (sharing upvars across threads in non-threadsafe Call objects, e.g.).

Gives us time to complete and evangelize Chrome Workers (a multi-month project if not multi-release).

Structured cloning with WrappedNative sharing

Description

In addition to chrome workers with a working constructor, we could add support for structured cloning of wrapped natives.

Advantages

This would allow a programming style that is more similar to what worked before with Thread.dispatch. Thread-safe C++ objects could be sent across to a different thread using postMessage and then operated on there.

Disadvantages

Implementation cost.

A new, different threading model, in addition to anything like Workers and the old nsIThreadManager models.