On 8/1/2013 11:25 AM, Arne Vajh?j wrote:
[...]
I think it is something like:
You can achieve what you want to do in two ways:
A) use Thread.stop
B) set a flag and let the thread do what it need to do to
terminate in a graceful manner
#A can be done safely in some cases and can not be done safely in
other cases. Even if it can be done safely, then it will require
significant analysis to get it right. And even if it gets done
right, then there is a high risk that that a bug will be introduced
during maintenance later, because the maintenance programmer do not
have the skill or the time to understand the subtleties of the
problem.
#B can always be done safely. It requires not much work. And
is relative maintenance friendly.
The O.P.'s use case involved third-party "suspect code" that
might dive into an infinite loop somewhere unexpected. I think
that rules out #B because you might overlook the fatal loop while
salting "should I stop now?" tests throughout the code (you might
not even have the freedom to insert tests). I'd say the "suspect"
nature of the code also rules out #A, if #A is possible at all
(I'm not convinced it is).
There's a #C, though: Run the suspect code in its own JVM, as
a separate process. If it goes silent for a long time, kill the
entire process. You don't need to worry about the integrity of a
JVM that's no longer living, and any corruption inside the dead
process' address space won't contaminate your own.