JDK-4385444 : (spec) InterruptedIOException should not be required by platform specification (sol)
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2000-11-02
  • Updated: 2024-04-12
  • Resolved: 2017-05-23
Related Reports
Relates :  
JDK-7188233 - UseVMInterruptibleIO flag deprecate for JDK8
Relates :  
JDK-6382902 - VM interrupted I/O feature put on an option switch (sol)
Relates :  
JDK-4514257 - Thread.interrupt() on InputStream.read() fails
Relates :  
JDK-4992463 - ClassLoading fails if the Thread's interrupt status is set
Relates :  
JDK-4764778 - Interrupted thread can't load classes from classes directory (sol)
Relates :  
JDK-4989068 - PrintStream.println() prints nothing in interrupted thread (sol)
Relates :  
JDK-6375934 - (cl) thread interruption interferes with classloading (sol)
Relates :  
JDK-6450036 - PrintStream.flush() clears thread interrupt flag (sol)
Relates :  
JDK-6554406 - Change switch UseVMInterruptibleIO default to false (sol)
Relates :  
JDK-4154947 - JDK 1.1.6, 1.2/Windows NT: Interrupting a thread blocked does not unblock IO
Relates :  
JDK-4250457 - InputStream.read() contains undocumented behaviour when interrupted
Relates :  
JDK-6296152 - System.err cannot print ThreadDeath
Relates :  
JDK-6348631 - remove the use of the HPI library from Hotspot
Relates :  
JDK-6491364 - Document Solaris-specific Hotspot switch UseVMInterruptibleIO as a Solaris platform rel note item
Relates :  
JDK-4329256 - interrupted thread no longer produces output (sol)
Description
InterruptedIOException has proven both problematic to implement and difficult
to use.  Among Sun's Java implementations, only the Solaris version has
implemented the throwing of this exception when a thread blocked in an I/O
operation is interrupted via the Thread.interrupt() method.  It is very
difficult, if not impossible, to implement this functionality on Win32 (see,
e.g., 4154947) and on some other Unix variants.  InterruptedIOException should
therefore not be a required part of the J2SE platform specification, and the
relevant Javadoc should be updated to reflect this.
Comments
The Interruptible I/O "feature" has been removed. From the Java SE API perspective java.io.InterruptedIOException appears in just a single place. java.net.SocketTimeoutException extends java.io.InterruptedIOException. It seems unnecessary to affect both source and binary compatibility to even attempt to remove this, therefore I am closing as 'will not fix'.
23-05-2017
EVALUATION Option switch UseVMInterruptibleIO has been back ported to Java SE 5 update 12 to enable uniform behavior across platforms with that release too. The plan now is to change the default setting of UseVMInterruptibleIO in Java SE 7 so that behavior on all operating systems is identical.
09-11-2006
EVALUATION New Hotspot switch UseVMInterruptibleIO has been added to Java SE 6 with a default setting of on/true such that Solaris-specific I/O interruption is still present as it has always been. That is, the effect of this new switch is to make Solaris-specific behavior controllable while keeping Java SE 6 behavior exactly as it was for Java SE 5 and earlier Java SE releases for Solaris. However, this switch can be set off/false to disable Solaris-specific interruption as follows: -XX:-UseVMInterruptibleIO By setting the switch to "-" (off/false) Java SE is made to behave uniformly for all platforms with respect to thread interruption as it relates to I/O. This switch has been documented in the Java SE release notes along with a notice that the default setting of the switch may be changed to off/false early in the Java SE 7 release cycle. That is, the plan is to eliminate this Solaris-specific behavior as the default in Java SE 7, while leaving open the choice to reenable the behavior. At the point this change is effected this and all related CRs will be declared complete. SDN comments about this proposed change are welcome.
09-05-2006
EVALUATION There is a definite need for pointing out that the circumstances in which an I/O operation can be interrupted vary. Applications cannot expect or depend on interruptibility that is Solaris-specific without giving up portability. Because the same level of support can't be offered everywhere, depending on this interruptibility (or its absence) should be carefully avoided. But what is meant by "interruptible I/O" and what aspect of it is Solaris-specific? The general term refers to the JDK's response of throwing InterruptedIOException when thread interruption is detected during the invocation of methods that can throw IOException. Solaris-specific "VM interruption" simply refers to the Solaris-specific source of interruption, while other, platform-independent code in the JDK also provides interruption for all OS types. Starting with jdk1.3(Kestrel), VM interruption of I/O was provided on Solaris only and this is still true for current Java SE. By "VM interruption" we mean that there is OS-specific behavior such that before the VM on Solaris initiates OS operations related to Java I/O, or after the operation has started but is found to have been interrupted by a signal (i.e. with errno==EINTR), then if thread interruption is detected (effectively, as if Thread.isInterrupted() would return true) the result will be a special VM error status that typically manifests as a thrown exception. In addition, on Solaris only, the JVM translates a Thread.interrupt() method invocation into an OS-level thr_kill call that sends a signal to a thread that might be pended for I/O. This is a major source, but not the only source, of the interruption with EINTR scenario described earlier. But in combination, the Solaris-specific source of thread signals and special handling of low level I/O operations translates into a marked difference in behavior for Java SE on Solaris vs on Linux and Windows. The interruptibility mechanism that was present in pre-1.3 versions of the JDK for Solaris could not be extended to Linux and Windows for various reasons including the maturity of threading support on Linux and resource usage complications on Windows. So, as he Description states, there has been a major contrast of Java SE depending on it's host OS type for some time. However, since jdk1.4(Merlin), the java.nio.channels package has provided portable mechanisms for interruptibility. See the InterruptibleChannel interface for details. Changing Solaris-specific behavior with respect to I/O interruption could not enable withdrawal of the InterruptedIOException class, as this exception is thrown in other contexts regardless of OS type.
08-02-2006