JDK-4082705 : (spec thread) interrupt signal issued before thread start is lost
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.2.0,5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_2.4
  • CPU: generic,sparc
  • Submitted: 1997-09-30
  • Updated: 2017-05-16
  • Resolved: 2005-09-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b55Fixed
Related Reports
Relates :  
Relates :  
Description
Name: akC45999			Date: 09/30/97



Sun's jdk implementations from 1.1 to 1.2M ignore interrupt signal 
(made by interrupt() call) if it was made before thread's start.
The specifications of java.lang.Thread does not specify such behaviour,
so we may expect that other implementors (and jdk1.0.2 did so)
will preserve the interrupt signal, which will lead to
incompatibility between the Sun and other JVM vendors.

Strictly speaking, the spec does not state that interrupt() called before start has
effect, so some common sence is applied: if a thread can be stopped before start,
why it can not be interrupted.
What would the spec people say?

// simplified version of the test
// javasoft.sqe.tests.api.java.lang.Thread.isInterrupted0103;

import java.io.PrintStream;

public class isInterrupted0103 {

  public static void main(String args[]) {
	Thread thrd=new Thread();
	thrd.interrupt();// 
	if (!thrd.isInterrupted()) {
		System.out.println("first interrupt signal lost");
	}
  }

}


Running the test:
novo37% javac isInterrupted0103.java
novo37% setenv CLASSPATH .
novo37% java isInterrupted0103
first interrupt signal lost


======================================================================

Comments
EVALUATION It doesn't seem to make much sense interrupting a thread that hasn't been started. I'll let the spec people be the judge. We'll change the implementation if they decide that's the right thing to do. sheng.liang@Eng 1997-10-16 Interpreting the spec as a mandate for handling interrupt status for threads that are not alive ignores the fact that applications could still miss out on interrupts, as there cannot be a second mandate preventing consumption of the status at the wrong time. That is, Thread implementations can check/catch/reset an interruption at arbitrary points, in effect robbing the post-start method invocation of the chance to catch the exception. For example it's perfectly legal to override the run method and for the overiding version of run consume interruption status or call a library routine such as Object.wait that does so. This isn't meant to imply that a simple test case can still easily show a difference in behavior, it's meant to stress the real risk that implementations saving status from pre-start interruptions will still be judged "broken." The potential for confusion is compounded by the fact that implementations have in fact diverged with respect to the behavior in question, and this divergence means that "fixing" one implementation risks breaking existing programs that are dependent on the other behavior. This all argues for a pragmatic spec change. Concurrency experts have suggested this added text for Thread.interrupt: "Interrupting a thread that is not alive need not have any effect." and this for interrupted and isIinterrupted: "A thread interruption ignored because a thread was not alive at the time of the interrupt, will be reflected by this method returning false."
11-06-2004