Lev Serebryakov wrote:
When XPCOM + XUL + JS + ... pretend to be a platform (XULRunner is
not released yet, I know, but it is here and I try to write full-blown
application absed on it, and I'm not alone!), it seems, that there are
threads (nsIThread), but not semaphores, events and/ore mutexes in
XPCOM.
Now it is even impossible to know, is thread running or finished
(join() will block, it is not a solution). And I can not find method to
post thread on other thread in JavaScript (nsIEventTarget has method
for this, but it marked as [noscript])!
Am I right? Is here any plans to add them to TRUNK? Maybe, I've
overlooked something?
Typically all of our threaded code is written in C++ and uses the NSPR
threading primitives (PRLock, PRMonitor, etc). There is currently no
scriptable access to these primitives, though it wouldn't be hard to provide.
See, for instance, bug 315442 which is about providing scriptable access to
nsIEventTarget.
Using XPCOM on multiple threads through JS (through XPConnect) is not very
well tested, and the few who venture there ('timeless' on irc) frequently
find threading bugs.
And is ther any way to signal some event from background thread to UI
one? For example, I need to notify UI thread, that background one
finished it work and data is ready to show
Typically you would post an event to the main-thread nsIEventQueue.
But can I ask what you're using threading for? Unless you're dealing with
external synchronous APIs almost all XUL app code can and should be written
without threads: our networking APIs provide good thread abstractions that
for the most part hide any need for threads.
--BDS
_______________________________________________
Mozilla-xpcom mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-xpcom
