I wrote a patch to do this as part of bug 1144481. It ends up being a nice simplification of the existing MediaPromise code, and can land independently.

How is it different the nsIEventTarget interface? Can it implement nsIEventTarget as SharedThreadPool does so that we can use it as an nsIEventTarget without knowing the thread pool guts under the hood?

Comment on attachment 8579080 [details] [diff] [review] Implement AbstractThread. v1 (In reply to JW Wang [:jwwang] from comment #3) > How is it different the nsIEventTarget interface? Can it implement > nsIEventTarget as SharedThreadPool does so that we can use it as an > nsIEventTarget without knowing the thread pool guts under the hood? They're similar, but AbstractThread guarantees that two events will not run at the same time - either because it's a single thread or because it's a task queue. In particular, using an nsIThreadPool where we use an AbstractThread would break a lot of our invariants. I think it does make sense to make this more explicit by specializing on nsIThread (instead of nsIEventTarget) and making the nsIEventTarget version QI to nsIThread, assert, and delegate. I'll do that now. Also, FWIW, AbstractThread is nicer to work with than nsIEventTarget, because of the lack of XPIDL goop.

I see. The semantics of nsIEventTarget is too loose to guarantee events will run in order. On the other hand, nsIThread is too strict which is mapped to an OS thread directly.

(In reply to JW Wang [:jwwang] from comment #7) > I see. The semantics of nsIEventTarget is too loose to guarantee events will > run in order. On the other hand, nsIThread is too strict which is mapped to > an OS thread directly. Precisely :-) https://hg.mozilla.org/integration/mozilla-inbound/rev/396bd3381cd4