Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Eric Sosman <esosman@comcast-dot-net.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: What is so bad aboud Thread.stop() ?
Date: Thu, 01 Aug 2013 11:49:36 -0400
Organization: A noiseless patient Spider
Lines: 37
Message-ID: <ktdvm7$bai$1@dont-email.me>
References: <8fe57dc2-a323-4821-941c-4036663cbce5@googlegroups.com> <51f9df70$0$52766$742ec2ed@news.sonic.net> <7bf3ea0e-533b-4cfe-a85d-ad75b5d3657c@googlegroups.com> <51fa7dea$0$298$14726298@news.sunsite.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 1 Aug 2013 15:43:04 +0000 (UTC)
Injection-Info: mx05.eternal-september.org; posting-host="0d73d8cc209bff1c6395088b400d0605"; logging-data="11602"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+K4bi80p/xxU2jQY76cM/L"
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
In-Reply-To: <51fa7dea$0$298$14726298@news.sunsite.dk>
Cancel-Lock: sha1:IymWM4oqBQJit2JiJMwIb2E5i+s=
Xref: csiph.com comp.lang.java.programmer:24871

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.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid