With OCSP enabled, we currently have several issues where Firefox/Thunderbird can not complete some operation, where the operation involves a cert that specifies an OCSP responder. As of today I'm aware of bug 337517, bug 353544, bug 353542. Christian Biesinger made me aware of a solution to all of the above issues. When OCSP verification is attempted from within the UI thread, when execution of application code is therefore blocked waiting for an OCSP request, we can call a new API function available on the trunk of Mozilla: NS_ProcessNextEvent() This will allow OCSP networking to continue while we are waiting for the results on the main thread. Thanks a lot to Christian for making me aware of this solution. Thanks a lot to Darin for rewriting thread manager that provides the new API.

Comment on attachment 239457 [details] [diff] [review] Patch v1 This seems okay, but I worry about leaving the PRLock to process arbitrary events. When we re-enter the lock, how do we know that our state is still as we expect it to be? Do we need more checks after re-entering the lock to ensure that this is safe?

(In reply to comment #2) > ... I worry about leaving the PRLock to process arbitrary > events. When we re-enter the lock, how do we know that our state is still as > we expect it to be? Do we need more checks after re-entering the lock to > ensure that this is safe? Darin, this lock does not protect any data. It is a temporary lock. Its only purpose is for creation of a dedicated condition variable for thread signaling. As of today this code will just wait in PR_WaitCondVar, while the other thread does all the work. (The call to PR_WaitCondVar unlocks the lock, too) The only reason why we hold that lock is because PR_WaitCondVar requires us to do so.

fixed on trunk

The checked in patch obsoleted bundle string OCSPDeadlock.