You can't always control what the thread is doing, like what code is being executed. Even if you put flags and ensure your code is periodically checking them, your code is not necessarily the only thing being executed by the thread. It may be calling into external code. You need a way to interrupt it.
> You can't always control what the thread is doing, like what code is being executed.
If this is the case then you can't use threads for this workload. If you're calling into some external code that could be doing whatever then one of the things it could be doing is holding locks. If you want a unit of execution you can murder with prejudice then you need the operating system's help which means a process.
On both Linux and Windows the situations where you can safely kill a thread is when you have complete control and knowledge of what's running in it, the very opposite of when people want to be able to kill threads.
No, that's exactly why you must not have "a way to interrupt it". Doing so could leave said external code in an invalid state and there would be no plausible way to do anything about it.
