зеркало из https://github.com/mozilla/gecko-dev.git
ed84376d75
There is a chance that a timer will be cancelled by its holder after the timer thread and all of the timers have been cleaned up. Doing this can result in a hang on the mutex lock, likely because the mutex is now pointing to something else. I'm not completely familiar with the inner workings of our timers so I'm not sure what the best fix is here. I decided to follow a pattern in our threading shutdown routines and flag the timer shutdown so the timers can't attempt to cancel past a certain point where they would be shutdown anyway. This is tricky because there are timers created during XPCOM shutdown all the way up until we shutdown the timer thread. Checking for the timer thread outside of the lock could also result in a race with timer shutdown. This value is an attempt to address this without breaking timers shutdown. Differential Revision: https://phabricator.services.mozilla.com/D113448 |
||
|---|---|---|
| .. | ||
| BinaryPath.h | ||
| FileLocation.cpp | ||
| FileLocation.h | ||
| GeckoProcessTypes.h | ||
| IOInterposer.cpp | ||
| IOInterposer.h | ||
| IOInterposerPrivate.h | ||
| LateWriteChecks.cpp | ||
| LateWriteChecks.h | ||
| MainThreadIOLogger.cpp | ||
| MainThreadIOLogger.h | ||
| NSPRInterposer.cpp | ||
| NSPRInterposer.h | ||
| Omnijar.cpp | ||
| Omnijar.h | ||
| PoisonIOInterposer.h | ||
| PoisonIOInterposerBase.cpp | ||
| PoisonIOInterposerMac.cpp | ||
| PoisonIOInterposerStub.cpp | ||
| PoisonIOInterposerWin.cpp | ||
| Services.py | ||
| SmallArrayLRUCache.h | ||
| XPCOM.h | ||
| XPCOMInit.cpp | ||
| XPCOMModule.h | ||
| XPCOMModule.inc | ||
| XREAppData.h | ||
| XREChildData.h | ||
| XREShellData.h | ||
| components.conf | ||
| mach_override.c | ||
| mach_override.h | ||
| moz.build | ||
| nsXPCOM.h | ||
| nsXPCOMCID.h | ||
| nsXPCOMCIDInternal.h | ||
| nsXPCOMPrivate.h | ||
| nsXULAppAPI.h | ||
| perfprobe.cpp | ||
| perfprobe.h | ||
| xpcom_alpha.def | ||
| xrecore.h | ||