Hi Joern, Hi Robert,
Thank you both for your comments.
To my understanding, Thread.interrupt is an intrathread communication
mechanism which does not work on most environments, e.g. Windows and
Linux. Thus, most code would use intra-thread communication mechanism
*other* than Thread.interrupt. As far as my personal experience goes,
I used Thread.interrupt in 1996, the second week after learning
Java. It did not work and I have never used Thread.interrupt ever
since. In books covering concurrency, whenever sample code tried to be
Thread.interrupt resistant in addition to proving its intended
intra-thread communication service, quickly became intractable.
Moreover, the cost of actually testing proper support for
Thread.interrupt in logback would be considerable.
I think it is saner to say that logback does NOT support
Thread.interrupt. We will however add such support if a logback user
suffers from the loss of the Thread.interrupt signal. I just want to
ascertain that the need is really there before making the
investment. The investment is not only sprkinling the appropriate
catch blocks with Thread.interrupt but also creating the necessary
test cases making sure that the code actually works.
On 08/07/2010 12:24 PM, Joern Huxhorn wrote:
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
