Fix, or at least make less common, deadlock in the thread sample.

Don't always deadlock when "Stop the last spawned thread" menu command is
selected. There is still a problem with a race condition which could result in
a crash when dereferencing an invalid pointer, but at least this doesn't
happen all the time, unlike the current bug.

Of course, the real solution would be to properly rewrite the sample to show
how thread deletion should be handled correctly...

See #14891.

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

diff --git a/samples/thread/thread.cpp b/samples/thread/thread.cpp
index b6adc3846d123deb73f7fd9b93f2e4eefab7e9e8..7948c35a473f92c83e452af84ec19c45ec5152ee 100644 (file)
--- a/samples/thread/thread.cpp
+++ b/samples/thread/thread.cpp
@@ -597,6 +597,8 @@ void MyFrame::OnStartThread(wxCommandEvent& WXUNUSED(event) )
 
 void MyFrame::OnStopThread(wxCommandEvent& WXUNUSED(event) )
 {
+    wxThread* toDelete = NULL;
+    {
     wxCriticalSectionLocker enter(wxGetApp().m_critsect);
 
     // stop the last thread
@@ -606,7 +608,15 @@ void MyFrame::OnStopThread(wxCommandEvent& WXUNUSED(event) )
     }
     else
     {
-        wxGetApp().m_threads.Last()->Delete();
+        toDelete = wxGetApp().m_threads.Last();
+    }
+    }
+
+    if ( toDelete )
+    {
+        // This can still crash if the thread gets to delete itself
+        // in the mean time.
+        toDelete->Delete();
 
 #if wxUSE_STATUSBAR
         SetStatusText(wxT("Last thread stopped."), 1);