Re: Mutable Objects and Thread Boundaries
Alan Gutierrez wrote:
With a terminal value to shutdown the queue, and with the thread
unexposed to the client, there seems to be no way to send an interrupt
to the thread, so it becomes the classic unreachable checked exception
block.
'InterruptedException' is not about SIGINT or other OS signals, but
about the Java method 'Thread#interrupt()'.
<http://download.oracle.com/docs/cd/E17409_01/javase/6/docs/api/java/
lang/Thread.html#interrupt()>
<http://download.oracle.com/docs/cd/E17409_01/javase/6/docs/api/java/
lang/InterruptedException.html>
There is excellent advice in /Java Concurrency in Practice/ (JCIP.
Part of the reason to catch it is that the JVM apparently can throw
spurious 'InterruptedException's.
Read JCIP (by Brian Goetz et al.).
Alan Gutierrez wrote:
There is such a way to accept a SIGTERM, Runtime.addShutdownHook, but it
is my understanding that it is up to the developer to implement the
orderly shutdown of her own threads. There is no mention of threads
being shutdown with interrupt.
In the case of my library, you would call a publicly exposed shutdown
method that would terminate the worker thread in a fashion that
indicated an orderly shutdown.
So there are no interrupts sent by the virtual machine at shutdown.
Interrupting a thread is something done deliberately.
Or not, if you get a spurious interruption.
I got to musing about daemon threads, too. I began to wonder if the JVM
simply stopped executing statements, or if the overly ambitions stop,
start, ThreadDeath mechanism still played some part in shutdown.
This program below shows that no interrupt it sent to the main thread
and nothing propagates out of the daemon thread, on OSX Sun JVM and on
Linux running Open JDK. Compile and run and send a SIGTERM using Ctl+C
Ctrl-C sends SIGINT, not that that is relevant to
'InterruptedException'.
or kill and the program stops dead.
public class SetDaemon {
public static void main(String[] args) {
Thread thread = new Thread(new Runnable() {
public void run() {
try {
for (;;) {}
} catch (Throwable e) {
e.printStackTrace();
if (e instanceof Error) {
throw (Error) e;
}
throw (RuntimeException) e;
}
}
});
thread.setDaemon(true);
thread.start();
try {
Thread.sleep(Long.MAX_VALUE);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
markspace wrote:
2) Another programmer might assume that any thread can be killed with an
interrupt, and might be confused or frustrated when it can't. In this
light, it's just a bit of future proofing and courtesy to make your
thread work in the standard way.
Alan Gutierrez wrote:
Point taken. I'll throw an exception instead. I maintain that this tread
is part of the internal state of the library and sending it an interrupt
is a programming error,
Or a spurious 'InterruptedException'.
but as a programming error, it should throw an
exception the moment the error is detected.
Unless it was a spurious exception.
--
Lew