Open Bug 999104 Opened 10 years ago Updated 2 years ago

Need way for an nsThread to shut itself down safely

Categories

(Core :: XPCOM, defect)

All
Windows XP
defect

Tracking

()

People

(Reporter: jesup, Unassigned)

References

Details

nsThreads have to be ::Shutdown() from another thread (typically MainThread), which is both annoying and a source of potential bugs (see bug 997286 for examples), because of the hoops you have to jump through to implement a "shut me down".  And this leads to semi-duplicate code in various parts of the tree; and thread leaks when people don't get their assumptions right (see CryptoTask).

nsThreadUtils (or something) should have a way to ask that a thread exit cleanly (call ::Shutdown()).  Even if (on some platforms?) this must bounce to MainThread, encapsulating this would be good.

related, but not the same: We should consider if it's useful for a 'thread' to be able to be created to process a single event and exit (which could also, behind the scenes, use a threadpool of transient worker threads).  This is being worked on another bug.
The basic requirement is that we call PR_JoinThread at some point. Currently the Shutdown() requirement exists just so that there is another thread to call jointhread. We can probably make this better like this:

* create an AsyncShutdown API that may be called from any thread including the target thread itself
* when the thread actually exits, it adds itself to a (linked) list of dead threads that need to be joined
* have the main thread join dead threads at the next event loop iteration or periodically
Blocks: 1022376
>The basic requirement is that we call PR_JoinThread at some point.

Any underlying reason why something like detached threads can't be used? In that case Shutdown() could just set a flag that causes the event loop to exit. (I'm not aware of the specific details of the Firefox implementation and could be spouting nonsense)
The big problem that we're solving is that most of our threaded code has dependencies on XPCOM globals like the component manager. So in order to shut down XPCOM, we have to make sure to "join" that code. Not specifically the thread itself, although joinable threads are the best way to do that.

We do use detached threads for some things like the DNS subsystem which isn't really XPCOM, but could block shutdown for no good reason.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.