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.
Agree. If genuine pre-emptive cancellation from the outside is needed, all languages support the primitive which allows that: a process.
Many of the tradeoffs that come from using a process rather than a thread descend directly from that property of support for arbitrary-point cancellation.
The only solution is the one being complained about--for a thread to voluntarily check if it needs to be cancelled.
Java deprecated stop() for good reasons.
"Those who cannot remember the past are condemned to repeat it."