JDK-4989068 : PrintStream.println() prints nothing in interrupted thread (sol)
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_9
  • CPU: generic
  • Submitted: 2004-02-05
  • Updated: 2006-02-02
  • Resolved: 2006-02-02
Related Reports
Duplicate :  
JDK-4329256 - interrupted thread no longer produces output (sol)
Relates :  
JDK-4385444 - (spec) InterruptedIOException should not be required by platform specification (sol)
Relates :  
JDK-4764778 - Interrupted thread can't load classes from classes directory (sol)
Description
This program:

public class HelloInterrupted {
    public static void main(String[] args) throws Exception {
	Thread.currentThread().interrupt();
	System.out.println("Hello");
    }
}

produces no output on solaris-sparc, It prints the expected output on
linux-i586 and windows-i586

###@###.### 2004-02-04
Comments
WORK AROUND Test for and clear pending interrupts before attempting interruptible I/O. For example: public class HelloInterrupted { public static void main(String[] args) { Thread.currentThread().interrupt(); if(Thread.currentThread().interrupted()) { // handle the interruption status here } System.out.println("Hello"); } }
26-09-2005
EVALUATION I've rolled this bug back to "cause known" since the fix is far from understood. It's clear that this is a side effect of interruptible I/O support that is present on Solaris but not on Linux and Windows but it's not clear what "fix" is possible that would not be interpreted as a different kind of bug. As mentioned above, catching InterruptedIOException interferes with output. On the other hand, one user's interference is another user's interruptible I/O! And although it might seem reasonable in the abstract to undo some current behavior with respect to output typically involving interactive devices, where, exactly, should the dividing line be? If instead of "Hello" a gigabyte of output is initiated, should the interruption be ignored? This is not meant to imply support for a feature that is platform-specific. The basic issue seems to be that users simply cannot avoid this difference in behavior when they don't perceive it to be desirable.
26-09-2005
EVALUATION This has to do with the semantics of interruptible I/O on Solaris, and the unusual documented behavior of PrintStream of catching InterruptedIOException and resetting the interrupted status bit. Doug Lea writes: This is mainly a policy issue: Under what conditions should various IO methods abort if interrupted? This is compounded by the fact that the platform runtimes differ about if/when they throw InterruptedIOExceptions. To handle this right would be too hard (for example, maybe allow interrupt policy setting methods in various IO classes), but we could consider adopting a couple of common rules of thumb: Generally, people would prefer if inputs abort on interrupt, but outputs continue. (This is because outputs will almost always unblock soon if they are stuck.) This could be done inside PrintStream. It would take a little work to do this, and might be dependent on details of underlying platform IO (so might have to be revisted if these change), but I'm pretty sure I could do it. I'll give it a try sometime over the next week. The input side is trickier: It generally DOES abort in a reasonable way. But it shouldn't in the particular case of classloading. I'm not sure offhand of the exact call sequence that leads to problems, but it seems plausible to me that this particular problem could be fixed. I'll look into this too. ###@###.### 2004-02-04
04-02-2004