JavaScript/HandlingThreads

From MozillaWiki
< JavaScript
Revision as of 00:39, 17 November 2010 by Gal (talk | contribs)
Jump to navigation Jump to search

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.

Nothing

Description

Advantages

Disadvantages

MT Proxies

Description

Advantages

Disadvantages

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

Environment cloning

Description

Advantages

Disadvantages

Env. cloning + global-MT-proxy

Description

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).

Disadvantages

ChromeWorkers w/ usable Constructor

Description

Advantages

Disadvantages

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.

Restoring MT object access

Description

Back out the removal of titles. Restore old partially crash behavior (which was pretty stable in practice, and only unsound in corner cases such as Call objects and dense arrays).

Advantages

Immediately restoration of 100% compatibility.

Disadvantages

Unsound. Will affect per-compartment GC. Performance loss (1%?). Maintenance and complexity cost, loss of a nice simplification. Can't move the property tree per-thread. We might be able to hang on to per-compartment GC for compartments that never do cross-thread access though.

Example Users

Yoono

FireFTP

Mozmill + IPC library (the actual IPC library doesn't yet work with Fx4, may not be important)