Threading

[Nille]

Hi,

I'm currently writing a toolbar that connects Firefox to our native
application (long story for a different day). I have a chain that looks
like this: Javascript <-> C++ (XPCOM) <-> ActiveX <-> Our App.

When connecting to our native app from Javascript, I invoke a method on
an XPCOM component which in turn responds with an event such as
"connected". The event is dispatched to javascript through observers.
This scenario works fine, as long as I stick to firing events in the
calling thread.

However, our native app continuously and asynchronously delivers events
that needs to be dispatched to javascript for processing in the
browser. This is where it fails; when fireing events in the calling
thread of a JS-invokation, it works; when firing events from an
arbitrary thread the "NotifyObservers"-method hangs, probably because
the script hangs. I haven't been able to find a definitive pattern for
when the method hangs, but the combination "arbitrary thread + alert()"
seems to do the trick, as well as calling other UI-related functions.

Are there any rules in particular that pertains to threading in XPCOM
or to Firefox extensions? I've looked around, but can see any clear
definitions as one does in e.g. Microsoft COM. Any idea why it hangs?

Regards,
Nille

PS
I posted another topic here:
http://groups.google.com/group/mozilla.dev.extensions/browse_thread/thread/c269b486b11ad7a4
In retrospect, this group seems more suitable.
DS

[Benjamin Smedberg]

Nille wrote:

> Are there any rules in particular that pertains to threading in XPCOM
> or to Firefox extensions? I've looked around, but can see any clear
> definitions as one does in e.g. Microsoft COM. Any idea why it hangs?

In general, most mozilla components are designed to be used only from the
main thread. If you are receiving notifications from another thread, you
should proxy those notification back to the main thread before you work on
them (this is how the networking code works, for example).

--BDS

[Nille]

Hi, and thanks for verifying this!

Are there any facilities in XPCOM for this? Would I be correct in
assuming that e.g. nsIDOMEventTarget::DispatchEvent would manage
marshalling the call into the appropriate thread? If so, I'll migrate
to that instead of using observers.

Regards,
Nille

[Boris Zbarsky]

Nille wrote:
> Are there any facilities in XPCOM for this?

Yes. Depending on your branch see nsIThreadManager (trunk) or
nsIEventQueueService (elsewhere). See also nsIProxyService, depending on what
you're doing.

> Would I be correct in
> assuming that e.g. nsIDOMEventTarget::DispatchEvent would manage
> marshalling the call into the appropriate thread?

No. All DOM access MUST happen on the main thread. This includes calls to
nsIDOMEventTarget::DispatchEvent.

-Boris

[Nille]

Thanks!

Regards,
Nille

[Christian Biesinger]

Nille wrote:
> Are there any facilities in XPCOM for this? Would I be correct in
> assuming that e.g. nsIDOMEventTarget::DispatchEvent would manage
> marshalling the call into the appropriate thread? If so, I'll migrate
> to that instead of using observers.

No, all the nsIDOM* interfaces are really only meant to be used on the
main thread and therefore do not do any marshalling.

Use nsIProxyObjectEventManager:
http://www.mozilla.org/projects/xpcom/Proxies.html
(but note that these interfaces have changed a bit on trunk (that is,
for Gecko 1.9/Firefox 3/SeaMonkey 1.5))

[Markus Stange]

Hi,

Nille wrote:
> Are there any facilities in XPCOM for this?

I started experimenting with threading as well and found a forum thread
[1] on mozillazine very helpful.

Then I transformed this code into a kind of C#-style[2] wrapper
(Threading.js[3]) which somehow works, at least using simple example
code[4].

Hope this helps,
Markus

[1]
http://forums.mozillazine.org/viewtopic.php?p=2431475&sid=ff6dd2b34499e4230ad32c16cce17674
[2] http://www.albahari.com/threading/
[3] http://tests.themasta.com/tmp/xpcomthreading/Threading.js
[4] http://tests.themasta.com/tmp/xpcomthreading/threadingExample.js