Re: Mutable Objects and Thread Boundaries
markspace wrote:
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.
See, I'd go the other way. Even though I don't personally know any way
your thread is exposed to a client either, I'd still let an interrupt
kill the thread. Two reasons for this:
1) There may be some way a client can send a SIGHUP or similar through
the console, which the JVM might propagate to all threads, for an
orderly shutdown (kill -9 is disorderly and abrupt).
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.
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
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();
}
}
}
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.
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, but as a programming error, it should throw an
exception the moment the error is detected.
--
Alan Gutierrez - alan@blogometer.com - http://twitter.com/bigeasy