I agree with Robert. According to http://download.oracle.com/docs/cd/E17476_01/javase/1.4.2/docs/api/java/io/InterruptedIOException.html : "An InterruptedIOException is thrown to indicate that an input or output transfer has been terminated because the thread performing it was interrupted."
This means that the threads interrupted state should indeed be restored after catching such an event. I can't emphasize enough how stupid I consider the existence of this issue - but obviously all code should be checked for this. I'm especially annoyed since IOUtils.closeQuietly() is broken, too, because it ignores this... I wouldn't go down the road of "it's just Solaris" since this is documented behavior that we obviously just weren't aware of. Cheers, Joern. On 08.07.2010, at 10:41, Robert Elliot wrote: >> Given that the issue is Solaris-specific and preventable with the >> -XX:-UseVMInterruptibleIO option, and given that the programming style >> for thread synchronization using interrupt() is in my opinion quite >> lame, I am tempted to ignore this issue. However, it is also true that >> some classes belonging to the JDK, i.e. PrintStream, invoke >> Thread.interrupt() after catching an InterruptedIOException. It >> follows that calling Thread.interrupt() looks like the sanctioned >> coding style. > > My understanding from reading Java Concurrency in Practice (pp 92-94 and > 138-144) is that it is more than sanctioned coding style - it's vital to > correct working of the interrupted thread model, and a well behaved consumer > of InterruptedException must restore the interrupted status unless it is > going to propagate the exception or is sure that the thread will terminate > immediately after catching it. > _______________________________________________ > Logback-user mailing list > [email protected] > http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list [email protected] http://qos.ch/mailman/listinfo/logback-user
