This function is needed for people whose needs don't map cleanly to
NS_DispatchToBackgroundThread, usually because they're using the event
target to do thread consistency checks. Once we have this function, we
can start converting singleton threads/thread pools that want to use
functionality like the above.

Backed out changeset 9364cff86a7e (bug 1584568) by dev's request

Push:
https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=9364cff86a7e135ee2ffed3edcebc5c1c718ad20

Backout:
https://hg.mozilla.org/integration/autoland/rev/666eabb8ba240aa2dc0fb9b13b1da00891ae3d97

I had the sheriffs back this out because this is not the right API. But the question of what is the right API presents some complications.

Why is this not the right API? Because most clients who would use this API -- those who are spinning up their own one-off threads (thread pools are a separate issue) -- are possibly relying on the linear execution of events submitted to their private thread. This replacement API does not give them that guarantee. It works currently, because the thread pool behind this API only has one thread at the moment -- which is a nice little footgun if we do decide to start bumping up the number of threads.

In fact, I'm not even sure that NS_DispatchToBackgroundThread is the correct API to give people, since the naming of the API is also implying that there is a single thread responsible for executing the events submitted...which is the case now by accident, but is not the final state where we want to end up. So we may want to revisit that at some point (fortunately, the only two clients of the API -- I think -- don't particularly care about the ordering of their submitted events).

So what do we do about NS_GetBackgroundEventTarget? We have an interface for what threads do -- nsISerialEventTarget -- and we have an API for imposing linear execution on a possibly multi-threaded event target -- mozilla::TaskQueue. So really we probably want a way to give people a TaskQueue for managing their own private "background thread", and the TaskQueue can be backed by our background thread pool.

Who takes responsibility for shutting down the TaskQueue? I'm not sure I want to rewrite all potential clients of NS_NewNamedThread to use the promise-based interface behind TaskQueue shutdown, though maybe it's less complicated than I think it is. We could just hand out references (or pointers, or whatever), and let the background thread target and the thread manager take responsibility for shutting everything down after xpcom-shutdown-threads.

TaskQueue also doesn't have the notion of nsIEventTarget's dispatch flags, though maybe we should just hand out the nsISerialEventTarget objects from here: https://searchfox.org/mozilla-central/source/xpcom/threads/TaskQueue.h#102-104 and not let people even know that TaskQueue is handling things under the hood. That would make lifetime management a lot simpler. We'd have to make the API obvious that you are getting some unique thing back and it is your responsibility to hold onto it; if it goes away, there's no way for us to rematerialize that exact pointer for you (the TaskQueue would of course still be alive, but we wouldn't know which one corresponds to your use case).

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:froydnj, could you have a look please?
For more information, please visit auto_nag documentation.

https://hg.mozilla.org/mozilla-central/rev/15a4203d36b0