Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

the state of JS threading with mozilla 1.9 / firefox 3

2 views
Skip to first unread message

Carl Shimer

unread,
Feb 18, 2008, 7:10:30 PM2/18/08
to
the state of JS threading with mozilla 1.9 / firefox 3

Hi,

I am working on a xulrunner / firefox 3 application. There are a
couple situations where I would like to run some tasks in a background
thread. I know that I can use C/C++ for background thread work as
long as I dispatch any user interface events/work onto the main thread
using a nsIrunnable class (in fact, I have this working for an XPCOM
service).

I would like to use javascript for the background thread (mainly for
code reuse).

According to the docs on developer.mozilla.org it looks like you can
use the new nsIThreadManager to run javascript on multiple threads.
For trivial test applications it appears to work as designed. I can
create a nsIRunnable object that does some trivial work (e.g send text
to the console logger). I can also dispatch runables back to the main
thread.

For more complicated applications it appears that multithreaded
javascript does not work well. In my case I need to iterate through a
bunch of files and do some operations using an xpcom object or two and
a shell application. Xulrunner will either crash or hang
nondeterministically (usually in the JS runtime). Adding
instrumentation code can help but I have gotten to the point where
xulrunner appears to crash in code between two log statements where
the JS engine should be executing straight javascript (no XPconnect
calls).

I suppose the next step is to build a debug version of xulrunner and
dig into the code (this project runs on windows right now and --enable-
debug falls over halfway through the build) However, it seems like
that might be a waste of time. Threads like
http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/5e7e968455f540f1/1e0187991a51ebc3?lnk=gst&q=thread+manager#1e0187991a51ebc3
don't inspire much confidence.

Is multithreaded JS simply not workable? Should the docs be amended
to say as much? Are there a set of guidelines for things you can and
can't do that aren't published anywhere?

My current plan is to run on the main thread and use a generator that
will yield work items that I can dispatch onto the main thread's event
queue. This should enable the UI to continue processing (e.g display
a progress bar).

Thanks,
Carl

Dan Mosedale

unread,
Feb 28, 2008, 3:03:40 PM2/28/08
to
Carl Shimer wrote:

> Is multithreaded JS simply not workable? Should the docs be amended
> to say as much? Are there a set of guidelines for things you can and
> can't do that aren't published anywhere?

Note that while JavaScript itself is threadsafe, much of Gecko is not.
The most notable restriction is that you can't touch the DOM from
anything other than the UI thread. From what I can see this isn't yet
documented on devmo, though as you point out, it should be. It is
listed on the documentation wishlist.

> My current plan is to run on the main thread and use a generator that
> will yield work items that I can dispatch onto the main thread's event
> queue. This should enable the UI to continue processing (e.g display
> a progress bar).

That sounds workable.

Dan

Sheppy

unread,
Feb 28, 2008, 4:01:21 PM2/28/08
to
On Feb 28, 3:03 pm, Dan Mosedale <dm...@mozilla.org> wrote:

> Note that while JavaScript itself is threadsafe, much of Gecko is not.
> The most notable restriction is that you can't touch the DOM from
> anything other than the UI thread.  From what I can see this isn't yet
> documented on devmo, though as you point out, it should be.  It is
> listed on the documentation wishlist.

The fact that you can't touch the DOM from anything other than the UI
thread is actually mentioned in several places, but there is not yet a
good article on safely doing threading in JavaScript in Mozilla, which
is something that needs to be written when time allows.

Eric Shepherd
Developer Documentation Lead
Mozilla Corporation

Mook

unread,
Feb 29, 2008, 11:44:57 AM2/29/08
to

Umm, isn't GC (in Mozilla, due to cycle collector) supposed to be
main-thread only? How the heck would one use JS in the background and
not introduce thread-safety problems? (Assume I'm a pure component that
never touches the DOM)

--
Mook

Benjamin Smedberg

unread,
Feb 29, 2008, 12:13:20 PM2/29/08
to
Mook wrote:

> Umm, isn't GC (in Mozilla, due to cycle collector) supposed to be
> main-thread only? How the heck would one use JS in the background and
> not introduce thread-safety problems? (Assume I'm a pure component that
> never touches the DOM)

xpconnect vetoes any GC that happens off the main thread.

--BDS

0 new messages