Bugzilla

There is also [one interesting instance](https://crash-stats.mozilla.org/report/index/2573bde1-6fe3-4724-810b-a955b0220719#allthreads) concerning the `BHMgr Monitor` and `Cookie` threads.

1. We enter phase `ShutdownPhase::AppShutdown`
2. (`MainThread`) notifies the `CookieService` to shutdown.
3. (`MainThread`) The `CookieService` starts a synchronous [`shutdown()`](https://hg.mozilla.org/mozilla-central/annotate/2426bd765f8b74744fa7042826423ec5ddca53a7/netwerk/cookie/CookiePersistentStorage.cpp#l562).
4. (`MainThread`) `nsThread::Shutdown()` is spinning the event loop, waiting for the thread to finish
5. (`BHMgr Monitor`) `BackgroundHangManager::MonitorThread` detects a hang and wants to report it (might have happened even earlier)
6. (`BHMgr Monitor`) `BackgroundHangThread::ReportHang` is called with [`mManager->mLock IS locked`](https://searchfox.org/mozilla-central/rev/a352cc827575823676717d53766c39710b54201a/toolkit/components/backgroundhangmonitor/BackgroundHangMonitor.cpp#512)
7. (`BHMgr Monitor`) For whatever cosmic reason, writing to file takes some time inside `nsLocalFile::OpenNSPRFileDesc`
8. (`MainThread`) `ProcessNextEvent` [wants to `BackgroundHangMonitor().NotifyWait();`](https://hg.mozilla.org/mozilla-central/annotate/2426bd765f8b74744fa7042826423ec5ddca53a7/xpcom/threads/nsThread.cpp#l1094) which wants to lock the same `mManager->mLock` already held by `BackgroundHangThread::ReportHang` and starves
9. (`Cookie` thread) In the meantime, the `Cookie` thread reached its end and is just waiting for the [`nsThreadShutdownAckEvent`](https://searchfox.org/mozilla-central/rev/a352cc827575823676717d53766c39710b54201a/xpcom/threads/nsThread.cpp#204,208) to be processed on the `MainThread`.

Also for performance reasons it seems questionable to me that a lock [used by frequent event processing](https://searchfox.org/mozilla-central/search?q=symbol:_ZN7mozilla21BackgroundHangMonitor10NotifyWaitEv&redirect=false) is held on the background thread for long-running tasks like hang-report disk writings.

Bob, :jya, the lock that blocks the main thread has been introduced relatively recently (2 years ago) by bug 1634253. 

Dragana, on a different side note the synchronous `nsThread::Shutdown()` in `CookiePersistentStorage::Close` could maybe be avoided in favor of `nsThread::AsyncShutdown()` ? It would not stop this from happening, of course, but there would be less blocking layers potentially stacking on the main thread.

There is also [one interesting instance](https://crash-stats.mozilla.org/report/index/2573bde1-6fe3-4724-810b-a955b0220719#allthreads) concerning the `BHMgr Monitor` and `Cookie` threads.

1. We enter phase `ShutdownPhase::AppShutdown`
2. (`MainThread`) notifies the `CookieService` to shutdown.
3. (`MainThread`) The `CookieService` starts a synchronous [`shutdown()`](https://hg.mozilla.org/mozilla-central/annotate/2426bd765f8b74744fa7042826423ec5ddca53a7/netwerk/cookie/CookiePersistentStorage.cpp#l562).
4. (`MainThread`) `nsThread::Shutdown()` is spinning the event loop, waiting for the thread to finish
5. (`BHMgr Monitor`) `BackgroundHangManager::MonitorThread` detects a hang and wants to report it (might have happened even earlier)
6. (`BHMgr Monitor`) `BackgroundHangThread::ReportHang` is called with [`mManager->mLock IS locked`](https://searchfox.org/mozilla-central/rev/a352cc827575823676717d53766c39710b54201a/toolkit/components/backgroundhangmonitor/BackgroundHangMonitor.cpp#512)
7. (`BHMgr Monitor`) For whatever cosmic reason, writing to file takes some time inside `nsLocalFile::OpenNSPRFileDesc`
8. (`MainThread`) `ProcessNextEvent` [wants to `BackgroundHangMonitor().NotifyWait();`](https://hg.mozilla.org/mozilla-central/annotate/2426bd765f8b74744fa7042826423ec5ddca53a7/xpcom/threads/nsThread.cpp#l1094) which wants to lock the same `mManager->mLock` already held by `BackgroundHangThread::ReportHang` and starves
9. (`Cookie` thread) In the meantime, the `Cookie` thread reached its end and is just waiting for the [`nsThreadShutdownAckEvent`](https://searchfox.org/mozilla-central/rev/a352cc827575823676717d53766c39710b54201a/xpcom/threads/nsThread.cpp#204,208) to be processed on the `MainThread`.

Also for performance reasons it seems questionable to me that a lock [used by frequent event processing](https://searchfox.org/mozilla-central/search?q=symbol:_ZN7mozilla21BackgroundHangMonitor10NotifyWaitEv&redirect=false) is held on the background hang monitor thread for long-running tasks like hang-report disk writings.

Bob, :jya, the lock that blocks the main thread has been introduced relatively recently (2 years ago) by bug 1634253. 

Dragana, on a different side note the synchronous `nsThread::Shutdown()` in `CookiePersistentStorage::Close` could maybe be avoided in favor of `nsThread::AsyncShutdown()` ? It would not stop this from happening, of course, but there would be less blocking layers potentially stacking on the main thread.