[concurrency-interest] Thread interruptionprotocol:InterruptedException is a "checked" exception, correct?
davidcholmes at aapt.net.au
Thu May 21 17:57:28 EDT 2009
Thread.interrupt() is a purely Java-level functionality - it exists only in the VM. It is not a "signalling" mechanism (by which I mean POSIX signals), and has nothing to do with "interrupts" (normal hardware and software notion). It is simply a mechanism to request a thread to cancel what it is doing via a simple flag, coupled with a handful of specific blocking methods that say "if a thread is interrupted on entry to this method, or is interrupted while blocked in this method, then it will return immediately and throw InterruptedException." In this way Thread.interrupt can be used to implement a cancellation mechanism, and any method that wants to make itself a cancellation point can declare that it will check the interrupt state and respond accordingly. (But all this is covered in detail in "Concurrent Programming in Java" and "Java Concurrency in Practice" ;-) ).
Class.forName - like most methods - doesn't say anything about Thread interruption, which means (in my view) that it should do nothing about it ie. it should ignore the fact that the thread might be interrupted, and if by some chance it encountered InterruptedException directly (which it can't rethrow) then it should simply re-assert the interrupt state of the thread (which is the standard advice for handling interruption).
One other area where it gets a little murky is "interruptible I/O" which was only ever enabled on Solaris - it can have unintended side-effects too, hence it's now disabled by default in the latest Java 6 and 7 VMs. Interruptible I/O is generally unworkable and has been replaced with more well-defined interruption semantics in the NIO package (streams/channels are closed upon interrupt). Again this is discussed in the books as well as, I expect, some onloine articles.
> -----Original Message-----
> From: peter.dunay.kovacs at gmail.com
> [mailto:peter.dunay.kovacs at gmail.com]On Behalf Of Péter Kovács
> Sent: Thursday, 21 May 2009 10:30 PM
> To: dholmes at ieee.org
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Thread
> interruptionprotocol:InterruptedException is a "checked" exception,
> Bingo! We use 1.5.0_15. Thank you, David, for this info! It helps a lot.
> May I push on with this issue?
> Can you, please, tell me how Class.forName is supposed to handle
> thread interruptions? Will/should it simply ignore them? (What else
> could it do about interruption.)
> Also, I am a bit uncertain about the notion of thread interruption in
> this context. Does it mean a purely Java mechanism? Inside the JVM
> only? Or does it translate to some operating system mechanism -- on
> some platforms, perhaps (on Solaris e.g.)? Are there ways to interrupt
> a Java thread apart from the Thread.interrupt() API call (through some
> operating system facilities e.g.)?
> On Wed, May 20, 2009 at 10:55 PM, David Holmes
> <davidcholmes at aapt.net.au> wrote:
> > I wrote:
> >> In fact I think this affects all JDK 5 versions of Hotspot.
> > It's just been fixed in 5u18
> > David
> >> David Holmes
> >> > -----Original Message-----
> >> > From: concurrency-interest-bounces at cs.oswego.edu
> >> > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Peter
> >> > Kovacs
> >> > Sent: Thursday, 21 May 2009 2:06 AM
> >> > To: Paulo Levi
> >> > Cc: concurrency-interest at cs.oswego.edu; Tom Hawtin
> >> > Subject: Re: [concurrency-interest] Thread interruption
> >> > protocol:InterruptedException is a "checked" exception, correct?
> >> >
> >> >
> >> >
> >> > Oh, I see Constructor.newInstance() as opposed to
> >> > But this probably irrelevant here as the stack trace fragment I
> >> > produced in my previous mail appears to show that the exception is
> >> > from Class.forName(String). Also, we call Constructor.newInstance()
> >> > instead of Class.newInstance():
> >> >
> >> > Class<?> cl = Class.forName(name);
> >> > Constructor constr = cl.getConstructor(argcl);
> >> > return constr.newInstance(args);
> >> >
> >> > I was just trying to apply Tom's input about passing exception
> >> > checking to the case we appear to have.
> >> >
> >> > Thanks for making me aware of the difference anyway.
> >> >
> >> > Peter
> >> >
> >> >
> >> > 2009/5/20 Paulo Levi <i30817 at gmail.com>:
> >> > > You're not reading the javadoc correctly:
> >> > > newInstance()
> >> > > "Note that this method propagates any exception thrown by
> the nullary
> >> > > constructor, including a checked exception. Use of this method
> >> > effectively
> >> > > bypasses the compile-time exception checking that would
> otherwise be
> >> > > performed by the compiler. The Constructor.newInstance method
> >> > avoids this
> >> > > problem by wrapping any exception thrown by the constructor in
> >> > a (checked)
> >> > > InvocationTargetException."
> >> > >
> >> > _______________________________________________
> >> > Concurrency-interest mailing list
> >> > Concurrency-interest at cs.oswego.edu
> >> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >> _______________________________________________
> >> Concurrency-interest mailing list
> >> Concurrency-interest at cs.oswego.edu
> >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
More information about the Concurrency-interest