gecko-dev/xpcom
Dana Keeler e48051a0ac Bug 1634065 - remove the nested event loop in nsComponentManagerImpl::GetServiceLocked r=nika
If the implementation of an XPCOM service constructor involves dispatching an
event to another thread and blocking the current thread on that event, a
deadlock can occur if the target thread is also attempting to obtain that
service at the same time.
For instance, say nsIExampleService needs to be constructed on the main thread,
but some code in thread T is attempting to get a handle on it. Suppose the
implementation checks which thread it's running on and dispatches a synchronous
event to the main thread to do the actual construction work in the case that it
is not on the main thread. Further suppose that before that event is run, other
code on the main thread also attempts to get a handle on nsIExampleService. The
XPCOM service machinery sees that another thread is in the process of
constructing nsIExampleService, so it must wait for that to complete. However,
the thread that is attempting to do this construction is waiting for an event
to be run on the main thread. Thus, these two threads are deadlocked.
Before this patch, the XPCOM service machinery worked around this problem by
processing events on the second thread until it could proceed. However, this
caused a nested event loop, which is bad for stability because all guarantees
relating to when events will run are violated. In particular, this could cause
reentrency into the TLS implementation, which is not expected and has caused
intermittent crashes.
This patch removes the nested event loop in
nsComponentManagerImpl::GetServiceLocked in favor of not synchronously
dispatching events in XPCOM service constructors. One way to fix such
constructors is to move the event dispatch and blocking outside of the XPCOM
service machinery. See the other patch in this bug for an example.

Differential Revision: https://phabricator.services.mozilla.com/D92800
2020-11-17 16:30:06 +00:00
..
base Backed out 24 changesets (bug 1666566, bug 1675409) for causing hazard failures in profiler/core/platform.cpp 2020-11-17 19:31:28 +02:00
build Bug 1673917 - Rename vprintf style nsTSubstring::AppendPrintf -> AppendVprintf. r=sg 2020-10-29 14:51:45 +00:00
components Bug 1634065 - remove the nested event loop in nsComponentManagerImpl::GetServiceLocked r=nika 2020-11-17 16:30:06 +00:00
doc
ds Bug 1676434 - Replace obsolete -moz-mac-yosemite-theme media query with a new -moz-mac-big-sur-theme media query. r=emilio 2020-11-16 20:43:35 +00:00
glue Bug 1654103: Standardize on Black for Python code in `mozilla-central`. 2020-10-26 18:34:53 +00:00
idl-parser Bug 1654103: Standardize on Black for Python code in `mozilla-central`. 2020-10-26 18:34:53 +00:00
io Bug 1665172 - Add nsIFile::MoveToFollowingLinks{,Native} methods r=nika 2020-11-10 15:56:47 +00:00
libxpt/xptcall
reflect Bug 1654103: Standardize on Black for Python code in `mozilla-central`. 2020-10-26 18:34:53 +00:00
rust Bug 1674773 - Use the dummy-load-as-a-fence trick for refptr.rs. r=nika 2020-11-10 21:11:58 +00:00
string Bug 1673670 - Add vprintf style nsVprintfCString + tests. r=xpcom-reviewers,sg 2020-10-29 14:55:07 +00:00
system Bug 1654103: Standardize on Black for Python code in `mozilla-central`. 2020-10-26 18:34:53 +00:00
tests Bug 1651774: Update mozilla/use-services rule for native Services implementation. r=Standard8 2020-11-06 18:58:33 +00:00
threads Backed out 24 changesets (bug 1666566, bug 1675409) for causing hazard failures in profiler/core/platform.cpp 2020-11-17 19:31:28 +02:00
windbgdlg Bug 1654103: Standardize on Black for Python code in `mozilla-central`. 2020-10-26 18:34:53 +00:00
xpidl Bug 1670357 - Remove `make` targets for cleaning: `clean`, `realclean`, `clobber`, `distclean`, `clobber_all`, `everything` r=firefox-build-system-reviewers,mhentges 2020-10-15 20:37:18 +00:00
moz.build Bug 1654103: Standardize on Black for Python code in `mozilla-central`. 2020-10-26 18:34:53 +00:00
xpcom-config.h.in