The original idea behind the current model was that we wanted ironclad guarantees
that consumers would always get a callback on their promise. But we now have use
cases where the consumer wants to forget about a promise (using the new
Disconnect()) feature, and in some cases wants to shut down the task queue that
the response is going to be dispatched on. In the case of this bug, we want to
avoid waiting for the longest outstanding timer promise to be resolved before
shutting down the MDSM.
So this patch fixes up the pieces needed to make this work:
* Loosening our invariants to allow dispatch targets to be released on any thread,
since MediaTaskQueue and nsIEventTarget both have thread-safe refcounting.
* Releasing mThisVal in Disconnect, so that we no longer depend on successful
dispatch to release it on the correct (dispatch) thread.
* Fiddling with various assertions.
We also make some assertions fatal in nightly/aurora builds while we're at it.
CLOSED TREE
Backed out changeset 584d91ffdf88 (bug 1135424)
Backed out changeset d86806ea63f4 (bug 1135424)
Backed out changeset e52401d30a67 (bug 1135424)
The original idea behind the current model was that we wanted ironclad guarantees
that consumers would always get a callback on their promise. But we now have use
cases where the consumer wants to forget about a promise (using the new
Disconnect()) feature, and in some cases wants to shut down the task queue that
the response is going to be dispatched on. In the case of this bug, we want to
avoid waiting for the longest outstanding timer promise to be resolved before
shutting down the MDSM.
So this patch fixes up the pieces needed to make this work:
* Loosening our invariants to allow dispatch targets to be released on any thread,
since MediaTaskQueue and nsIEventTarget both have thread-safe refcounting.
* Releasing mThisVal in Disconnect, so that we no longer depend on successful
dispatch to release it on the correct (dispatch) thread.
* Fiddling with various assertions.
We also make some assertions fatal in nightly/aurora builds while we're at it.
This is necessary because we're going to want to start disconnecting sample
and seek requests directly from the state machine thread, and the machinery
asserts that disconnection happens on the same thread as resolution.
More generally, this is the right thing to do architecturally, and will help
wean us off the monitor.
These were accidental and redundant, because refcounted classes get this behavior
automatically. And this is very lucky, because it turns out that our MOZ_COUNT_*
infrastructure can't handle varying-sized instances identified with the same
string, which is exactly what we can get with these templated types.
The only remaining use of these macros is on the non-templated ThenValueBase,
which is happily not variable-sized. \o/
