Eric Shepherd wrote:
> I'm preparing to start writing up documentation on how to do threading
> correctly in JavaScript using nsIThread, and could use some guidance,
> since I've not yet actually done it myself.
I'm surprised you're working on this... I don't know of *anyone* who does
this correctly, and it's almost possible using any of our current codebases
to do it productively.
The only pattern I can think of where threads could be useful in JS today is
worker threads that perform synchronous actions and then fire an event back
to the main thread. There are a couple rules to begin with:
1) Never block the main thread
2) Never access non-threadsafe objects from off the main thread. This
includes almost all XPCOM objects, including all of the DOM.
This means that you can never do multi-threading from DOM script (because
the global JS object is a DOM object), it can only be attempted from JS
components.
3) actions that are complex or block on network activity can be performed on
worker threads. However, because JS does not have access to any of the
"ordinary" threading primitives like locks, monitors, etc. the results of
such actions can only be sent back to the main thread through events. In
fact, after a thread has been created events (or XPCOM proxies, which are
wrappers around events) are basically the only way to communicate back and
forth between threads.
I think that you might do well to document XPCOM proxies first, and then go
back and document threading in general. XPCOM proxies are much more likely
to be used by general code.
--BDS
