Is there a situation where not calling stopThread before destruction is acceptable? I think probably not and maybe it’d be good to assert if the Thread destructor is called and stopThread hasn’t been called with a suitable timeout whether or not the thread is still running…
Certainly we use it all over the place and pretty much it’s bug if stopThread wasn’t called manually with a suitable timeout.
Can anyone think of a situation where it’d be wrong to assert on failure to call stopThread?
+1 !!
How would you determine “a suitable timeout”, and what would the assert look like for that requirement?
The assert was to check that stopThread was called on destruction at all really. Otherwise you can go on assuming your thread will have stopped say by the time the app quits and not have stopThread in there - and then you’ve just got a bug waiting to happen.
The problem is, that if you get into the destructor of juce::Thread, it is already too late to call stopThread or to wait, because the thread is running a virtual function.
It needs to be handled in your sub-class.
Yes, so the assert is “has stopThread already been called”
