Opened 11 years ago

Closed 10 years ago

#9516 closed defect (fixed)

wxThread Pause in MSW Crashes

Reported by: queenorych Owned by:
Priority: normal Milestone:
Component: wxMSW Version: oldstable-latest
Keywords: wxThread::Pause Cc:
Blocked By: Blocking:
Patch: no


In a MSW build using the latest 2.8.7 (or svn) applications using wxThread::Pause and resume are easily susceptible random deadlocks. For example, simply using wxDirTraverser in a thread can randomly cause issues. The problem steams from msw's suspendthread function, which immediately suspends the thread. I think wxThread::Pause should act the same as it does in unix using TestDestroy() as pause points. This should make it easier to prevent deadlocks by pausing where appropriate, and provide a more uniform response across all platforms.

This function is primarily designed for use by debuggers. It is not intended to be used for thread synchronization. Calling SuspendThread on a thread that owns a synchronization object, such as a mutex or critical section, can lead to a deadlock if the calling thread tries to obtain a synchronization object owned by a suspended thread. To avoid this situation, a thread within an application that is not a debugger should signal the other thread to suspend itself. The target thread must be designed to watch for this signal and respond appropriately.

Attachments (1)

thread_diff.cpp download (6.0 KB) - added by queenorych 11 years ago.
Patch for 2.8.7 using semaphore to pause and not SuspendThread

Download all attachments as: .zip

Change History (4)

comment:1 Changed 11 years ago by vadz

  • Status changed from new to confirmed

I agree that this should be fixed. Any patches changing Suspend() to behave as suggested would be welcome.

Changed 11 years ago by queenorych

Patch for 2.8.7 using semaphore to pause and not SuspendThread

comment:2 Changed 11 years ago by queenorych

I'll be happy to do write a patch the subversion, if it looks ok to you and it'll actually be used in some fashion.

comment:3 Changed 10 years ago by queenorych

  • Resolution set to fixed
  • Status changed from confirmed to closed

This appears to have been fixed in 2.8.9

Note: See TracTickets for help on using tickets.