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
This commit is contained in:
parent
e5a1bd6409
commit
2450225e87
@ -1778,14 +1778,15 @@ static void ScheduleThreadForDeletion()
|
||||
|
||||
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;
|
||||
|
||||
// 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?") );
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user