See bug 1146416.
Aren't normal assertions enough? Or do people not test their patches using debug builds? (that would be very worrisome)
DEBUG builds of B2G were painfully slow for a long time (maybe still are?) so release-mode assertions for threadsafety became a necessity long ago. But I think we limited that so that MOZ_RELEASE builds were unaffected.
I had mostly e10s in mind here. But sure, these IPC code paths shouldn't be that hot, at least not anything comparing to bug 907914, which caused significant performance regressions and was then disabled in normal cases (bug 919380).
(In reply to Ben Turner <unresponsive until 3/30> (use the needinfo flag!) from comment #2) > DEBUG builds of B2G were painfully slow for a long time (maybe still are?) Bug 845886 hasn't seen much in the way of informative updates since the not-entirely-nice comment I left on it in 2013. > so release-mode assertions for threadsafety became a necessity long ago. But > I think we limited that so that MOZ_RELEASE builds were unaffected. See also MOZ_DIAGNOSTIC_ASSERT from bug 1129247. For the specific case of bug 1146416, the initial patch may have been tested adequately on a debug build, but the automated tests don't cover the case where I introduced a thread-safety regression. As far as I know we're not doing automated coverage reporting to detect test deficiencies like that.
Bug 1151650 is another instance of off-main-thread main-thread-only IPC. (Bug 1148650 might catch these indirectly, assuming the overhead is acceptable, but I don't know offhand if it's guaranteed to do so.)
Created attachment 8588799 [details] [diff] [review] patch The IPC code is cold enough that the cost won't matter, so let's just do this.