Hi all, After seeing many, many bugs about difficulty of writing code that properly handles NSS shutdown during XPCOM profile teardown, I think the only reasonable way forward is to simply make it so that NSS never shuts down--including in debug builds.
This will greatly simplify lots of code--not just code in security/manager, but also code in WebRTC, DOM (DOMCrypt), Toolkit (toolkit/identity), and Necko (netwerk/). We already have a significant amount of code that is already running in Firefox every day, but which doesn't handle NSS shutdown correctly. Changing PSM so that NSS never shuts down is an easy thing for me to do. But it would have the following negative implications: 1. If we don't We will need to mask out lots of memory leaks in memleak-reporting builds, because we'll have a lot of memory allocated that would only get freed during NSS_Shutdown. 2. Because NSS reads and writes to files in the profile directory, the profile directory must be readable and writable up until process exit. The current rules for XPCOM shutdown say that services must stop doing disk I/O well before then; we would need to change the rules. It is safe to do so? 3. Some buggy PKCS#11 modules (such as smart card readers) may need to be updated to support this. (A PKCS#11 module should gracefully handle the process exiting without "proper" shutdown, because it has to deal with programs crashing, but I've heard rumors that some don't.) The positive benefits: 1. Code that uses NSS would avoid race conditions at shutdown. 2. Code that uses NSS would be much easier to write (especially code that runs off the main thread). No more nsNSSShutDownObject, no more nsNSSShutdownPreventionLock, etc. 3. Code that uses NSS, including our SSL stack in particular, would be much efficient, because we could avoid using synchronization primitives (mutexes, semaphores) just to check for and prevent NSS shutdown. 4. Shutdown will be faster. 5. We will likely resolve a lot of shutdown-related bugs very easily. Please let me know if you have any questions or objections to doing this. FWIW, we would not be the first browser based on NSS to take this road. Cheers, Brian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
