Thread::stopThread should return a bool

[TheVinn]

Thread::stopThread should return the bool “threadDidExit” which is false if the thread had to be killed for a timeout.

I’ve also changed Thread::stopThread to have a default parameter of -1. And I changed Thread::~Thread to call stopThread with an infinite timeout. For strict applications, it can cause undefined behavior when a thread is forced to exit that way. I would rather the program hang than get undefined behavior.

If people need the feature of forcibly having threads killed then they should ask for it explicitly. I think its a bad programming practice.

The only reason I’m using it now is for unit testing synchronous socket operations which are supposed to never complete.

[jules]

Thanks - yes, I agree it should return a bool, I’ll sort that out.

As for the timeout it uses in the destructor, I’m not sure that matters too much because if your code gets to that point, it’s already well into “undefined behaviour” territory, and an assertion has been hit. I made it forcibly kill the thread so that there’s a chance that an app might struggle through and have a better outcome for the user, but it’d definitely still be a bug if that code gets executed.

(Looking at the class again, I should actually make that point clearer in the comments…)

[TheVinn]

As for the timeout it uses in the destructor, I’m not sure that matters too much because if your code gets to that point, it’s already well into “undefined behaviour” territory, and an assertion has been hit.

Ahhhh…yes… of course, you’re right! As usual. The derived class is already gone by then. In beast I will have to call fatal_assert, or FatalError at that point. The rules are more strict for peer to peer servers, they can’t be allowed to continue in that state.