Warum das Interrupt-Bit in einem Callable setzen?

Also, diese Ressource (http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html) schlagen vor, das Interrupt-Bit in einem Thread zu setzen, wenn dieser Thread sich nicht mit dem Interrupt selbst befasst. "Damit der Code weiter oben auf dem Aufrufstapel von der Unterbrechung erfahren und darauf reagieren kann, wenn er dies möchte. "

Angenommen, ich verwende einen ExecutorService, um etwas in einem anderen Thread auszuführen. Ich konstruiere ein Callable und übergebe dieses Callable an ExecutorService.submit (), das einen Future zurückgibt. Wenn der Callable unterbrochen wird und dann das Interrupt-Bit zurücksetzt, löst der verknüpfte Future keine InterruptedException aus, wenn Future.get () aufgerufen wird. Also, was wäre der Zweck des Setzens des unterbrochenen Bits in der aufrufbaren Datei, wenn diese Zukunft der einzige Weg ist, auf den der Haupt-Thread Zugriff hat.

class MyCallable implements Callable<String> {
  @Override
  public String call() {
    while (!Thread.currentThread().isInterrupted()) {
    }
    Thread.currentThread().interrupt();
    return "blah";
  }
}

 ExecutorService pool = makeService();
 Future<String> future = pool.submit(new MyCallable());
 // Callable gets interrupted and the Callable resets the interrupt bit.
 future.get(); // Does not thrown an InterruptedException, so how will I ever know that the Callable was interrupted?

Antworten auf die Frage(2)

Ihre Antwort auf die Frage