JavaScript/HandlingThreads
|
THIS PAGE MAY BE OUTDATED |
| This article is in parts, or in its entirety, outdated. Hence, the information presented on this page may be incorrect, and should be treated with due caution until this flag has been lifted. Help by editing the article, or discuss its contents on the talk page. |
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: fix bug 612745 to enforce the 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.
Followup bugs: bug 618126 and bug 618128.
Here are the choices we have. We can pick more than one.
Contents
Nothing
Description: Do nothing.
Advantages: No work. No added schedule risk. Minimizes future maintenance cost. Keeps compartmental GC alive as a near-term goal.
With the landing of bug 608171, extensions will be able to create chrome workers like so:
var factory = Cc["@mozilla.org/threads/workerfactory;1"]
.createInstance(Ci.nsIWorkerFactory);
var worker = factory.newChromeWorker(scriptURL);
Disadvantages: Not source-compatible with extensions using thread.dispatch(). Porting is not really possible for use cases involving WNs.
ChromeWorkers w/ usable Constructor
Description:
Advantages: Sounds easy!
Disadvantages: Not sure what it means.
MT Proxies
Description: See bug 566951.
Advantages:
Disadvantages: Not possible on non-global scope objects, which must be native (Call, Block, DeclEnv).
- What are the consequences for compartmental GC? For moving the property tree to be per-thread? How close is the existing patch to being ready? Does it properly handle sharing Functions across threads, given methodjit? How source-compatible is it with the use cases we want to fix? --jorendorff
Environment cloning
Description: Clone the script of the function being dispatched and its scope.
Advantages:
Disadvantages: Likely wouldn't be source-compatible for some users, since closed-on state, including global data structures, would be copied, not shared.
Env. cloning + global-MT-proxy
Description: As above, but instead of cloning globals, proxy them across threads.
Advantages:
Very nearly 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: The complexity of environment cloning plus MT proxies.
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. Instead of cloning, the underlying C++ object would be passed across threads and a new WrappedNative created in the new thread.
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: Immediate restoration of 100% compatibility.
Disadvantages: Unsound. Will affect per-compartment GC. Performance loss (according to jorendorff in bug 606029, 8% on some V8 tests without affecting the number of GCs). 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.
