[MSW] thread sample deadlock

[ericj]

To reproduce:
- start unmodified "thread" sample.
- select "thread -> start a new thread"
- select "thread -> stop the last spawned thread" before the thread terminates on its own (before counter reaches 10)

Program deadlocks and can only be killed through task manager.

I traced the problem down to an infinite loop in wxThreadInternal::WaitForTerminate "msw/thread.cpp". The call
result = traits->WaitForThread(m_hThread, waitMode);
(line 819 in today's SVN) always returns "WAIT_OBJECT_0 + 1", so that it never leaves the do/while loop.

I use threads often in my own projects and never had that problem. I have no idea what the sample does differently to cause this problem.

Tested with VS2003 + VS2005 under XP/32

[catalin]

This looks like a problem with the sample, because:
- MyFrame::OnStopThread() will enter wxGetApp().m_critsect and then calls Delete() which waits for the thread to exit;
- MyThread::Entry() tries to enter wxGetApp().m_critsect to check for wxGetApp().m_shuttingDown.

The patch attached improves the situation a bit by making "Stop the last spawned thread" option usable (it is completely unusable now). But it can still lead to a crash in the rare case when the main thread tries to delete a secondary thread that just deleted itself..

[VZ]

(In [73568]) 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.