- Converted the inferior to use <thread> so that it can compile cross-platform
- Set a thread's state to eStateStopped when it's suspended.
- Don't set the resume state in WillResume. That's just a hook for derived Thread classes to do bookkeeping.
- Adjust the expectations in the test to match reality.
Details
Diff Detail
Event Timeline
Do the multithreaded tests actually pass on Windows now after this, or do
they just get farther but fail on something else?
The particular test this addresses now passes. The other one that I'd gotten working earlier (TestNumThreads) continues to pass.
The rest still fail to compile because they depend on pthreads, but I'm hopeful they will work once I convert them to std::threads, which is what I plan to attempt next.
test/functionalities/thread/break_after_join/TestBreakAfterJoin.py | ||
---|---|---|
81–86 | If the STL is creating some magic threads behind the scenes in addition to the ones you requested, then I wonder if their orders will line up correctly. This might still fail if there are actually 7 threads, and the 7th one corresponds to one that actually hit the breakpoint. Maybe a better check is something like: threads_stopped = 0 for i in range(0, num_threads): thread = process.GetThreadAtIndex(i) if (thread.IsStopped()) threads_stopped = threads_stopped + 1 self.assertEquals(threads_stopped, 6, "Incorrect number of threads stopped!") |
test/functionalities/thread/break_after_join/TestBreakAfterJoin.py | ||
---|---|---|
81–86 |
Nope, they are all stopped when the breakpoint hits, so the number of stopped threads will be at least 6. In the case of Windows, it's 9, regardless of which one hits. I could loop through all the threads and assert that they're stopped, but the test for the number of threads must be expressed as >= 6. |
If the STL is creating some magic threads behind the scenes in addition to the ones you requested, then I wonder if their orders will line up correctly. This might still fail if there are actually 7 threads, and the 7th one corresponds to one that actually hit the breakpoint.
Maybe a better check is something like: