Path: csiph.com!usenet.pasdenom.info!news.albasani.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: markspace <markspace@nospam.nospam>
Newsgroups: comp.lang.java.programmer
Subject: Re: What is so bad aboud Thread.stop() ?
Date: Wed, 14 Aug 2013 19:10:23 -0700
Organization: A noiseless patient Spider
Lines: 58
Message-ID: <kuhdak$l7h$1@dont-email.me>
References: <8fe57dc2-a323-4821-941c-4036663cbce5@googlegroups.com> <ede0c691-85eb-4977-8644-27078248ed9d@googlegroups.com> <b6q109Fsua7U1@mid.individual.net> <7cb96188-91ce-4c2b-ace8-5eeb1b30815e@googlegroups.com> <b6vilcF4judU1@mid.individual.net> <5f47910f-5450-4578-818c-cac2d4b6f436@googlegroups.com> <39a5e684-7cf8-4f00-ba3b-7e280b19d669@googlegroups.com> <b343ce47-aeff-408b-943e-9bba4b280504@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 15 Aug 2013 02:10:29 +0000 (UTC)
Injection-Info: mx05.eternal-september.org; posting-host="fba3415ba68d85d643935af2f52f0b4b"; logging-data="21745"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19XB6rm4gF0ixe7UjlJJ9o8dRKyTXJztHw="
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
In-Reply-To: <b343ce47-aeff-408b-943e-9bba4b280504@googlegroups.com>
Cancel-Lock: sha1:xys0crL4qZOD/Pb77JnMQAruP4s=
Xref: csiph.com comp.lang.java.programmer:24995

On 8/14/2013 8:55 AM, taqmcg@gmail.com wrote:

> The cooperative Thread.interrupt() approach implies that the code
> that might be interrupted knows about this, i.e., the worker code is
> aware that there is some monitor.  It needs to  periodically check
> the interrupt flag and do something.  This couples the invoker to the
> invoked in a way that's a bit unattractive.


Several low level APIs in Java check for the interrupt flag, so if your 
library is calling these methods, it will check for interrupts implicitly.

Object.wait(), Thread.sleep(), most of the IO library, probably some 
more which I don't recall at the moment.

Also, if you're going to be dealing with threads at all, get yourself a 
copy of Java Concurrency in Practice.  It's *the* state of the art for 
working with threads in Java.

I'll also link to this article by its author:

<http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html>

I found your code a little baroque, so I wrote what I think is a simpler 
example.  Notice I never actually check the interrupt flag, but the code 
terminates fine.  If you comment out the call to interrupt(), then the 
program does not terminate.

package quicktest;

/**
  * @author Brenden Towey
  */
public class ThreadInterrupt
{
    public static void main( String[] args ) throws Exception
    {
       Thread t = new Thread( new Wait() );
       t.start();
       Thread.sleep( 50 ); // wait a bit
       t.interrupt();
       t.join();
       System.out.println( "Done!" );
    }

    private static class Wait implements Runnable {
       @Override  public synchronized void run() {
          try { wait(); }
          catch ( InterruptedException ex ) {}
       }
    }
}

OTOH hand if your library never makes any calls that do check for the 
interrupt flag, well I'm pretty sure there's no chance of this working. 
  I'd still really prefer you find a way to make it work though;  you're 
spending a lot of time here to implement something that is fundamentally 
broken (i.e., Thread.stop()).