Don't lock global mutex when deleting wxThread to avoid deadlocks.

Calling out the user-defined wxThread dtor while holding gs_mutexDeleteThread
lock is a bad idea as it may result in deadlocks if the dtor deletes another
thread. Only lock the mutex directly before manipulating the data it protects.

Thanks to Neno Ganchev.

Closes #11501.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62781 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

diff --git a/src/unix/threadpsx.cpp b/src/unix/threadpsx.cpp
index 700fd19324c2ab5dc83accc6c38be86657c84666..142268d1b069b98cb26d1c989c9ec5e94ef99006 100644 (file)
--- a/src/unix/threadpsx.cpp
+++ b/src/unix/threadpsx.cpp
@@ -1778,14 +1778,15 @@ static void ScheduleThreadForDeletion()
 
 static void DeleteThread(wxThread *This)
 {
 
 static void DeleteThread(wxThread *This)
 {

-    // gs_mutexDeleteThread should be unlocked before signalling the condition
-    // or wxThreadModule::OnExit() would deadlock
-    wxMutexLocker locker( *gs_mutexDeleteThread );
-

     wxLogTrace(TRACE_THREADS, wxT("Thread %p auto deletes."), This->GetId());
 
     delete This;
 
     wxLogTrace(TRACE_THREADS, wxT("Thread %p auto deletes."), This->GetId());
 
     delete This;
 

+    // only lock gs_mutexDeleteThread after deleting the thread to avoid
+    // calling out into user code with it locked as this may result in
+    // deadlocks if the thread dtor deletes another thread (see #11501)
+    wxMutexLocker locker( *gs_mutexDeleteThread );
+

     wxCHECK_RET( gs_nThreadsBeingDeleted > 0,
                  wxT("no threads scheduled for deletion, yet we delete one?") );
 
     wxCHECK_RET( gs_nThreadsBeingDeleted > 0,
                  wxT("no threads scheduled for deletion, yet we delete one?") );