Thread.interrupt works fine in modern JVMs including Linux. In fact, Our workaround to checking for changes to logback.xml was to write a s ServletContextListener that sleeps for some amount of time and then checks the timestamp. However, during shutdown it would hang waiting for the poll interval to complete so we added a call to interrupt to cause it to wake immediately. This works fine on every platform we run it on.
Concurrency in Practice by Brian Goetz has a good writeup on how thread interruption works and what it guarantees and what it doesn't. Ralph On Jul 12, 2010, at 6:05 AM, Ceki Gülcü wrote: > 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 _______________________________________________ Logback-user mailing list [email protected] http://qos.ch/mailman/listinfo/logback-user
