Chapter 13: Thread Pooling

	Chapter 15 - Breaking Out of a Blocked I/O State
	Java Thread Programming
	Paul Hyde


The read() Method Ignores Interrupts and Stop Requests


The read() methods of most subclasses of InputStream in the JDK ignore interrupts and dont even respond when the blocked thread is stopped . One notable exception is the PipedInputStream class, whose read() method does respond to interrupts by throwing an InterruptedIOException .


The class DefiantStream (see Listing 15.1) shows that when a thread is blocked waiting to read data from the keyboard, it does not respond to an interrupt or a stop request.


Listing 15.1 DefiantStream.javaDemonstration of interrupt() and stop() Being Ignored


1: import java.io.*;

3: public class DefiantStream extends Object {

4: public static void main(String[] args) {

5: final InputStream in = System.in;

7: Runnable r = new Runnable() {

8: public void run() {

9: try {

10: System.err.println(

11: about to try to read from in);

12: in.read();

13: System.err.println(just read from in);

14: } catch (InterruptedIOException iiox) {

15: iiox.printStackTrace();

16: } catch (IOException iox) {

17: iox.printStackTrace();

18: //} catch (InterruptedException ix) {

19: // InterruptedException is never thrown!

20: // ix.printStackTrace();

21: } catch (Exception x) {

22: x.printStackTrace();

23: } finally {

24: Thread currThread =

25: Thread.currentThread();

26: System.err.println(inside finally:\n +

27: currThread= + currThread + \n +

28: currThread.isAlive()= +

29: currThread.isAlive());

30: }

31: }

32: };

33:

34: Thread t = new Thread(r);

35: t.start();

36:

37: try { Thread.sleep(2000); }

38: catch (InterruptedException x) { }

39:

40: System.err.println(about to interrupt thread);

41: t.interrupt();

42: System.err.println(just interrupted thread);

43:

44: try { Thread.sleep(2000); }

45: catch (InterruptedException x) { }

46:

47: System.err.println(about to stop thread);

48: // stop() is being used here to show that the extreme

49: // action of stopping a thread is also ineffective .

50: // Because stop() is deprecated, the compiler issues

51: // a warning.

52: t.stop();

53: System.err.println(just stopped thread, t.isAlive()= +

54: t.isAlive());

55:

56: try { Thread.sleep(2000); }

57: catch (InterruptedException x) { }

58:

59: System.err.println(t.isAlive()= + t.isAlive());

60: System.err.println(leaving main());

61: }

62: }

The InputStream used in this example is System.in (line 5). It simply passes lines of input from the keyboard to the stream. Input is passed a line at a time from the keyboard to System.in so the Enter key must be pressed to send the characters typed. A new Runnable and a new Thread are created (lines 735) to block trying to read bytes from in ( System.in ). This new thread will block on read() until a line is typed in on the keyboard and the Enter key is pressed (line 12). If any of several types of Exception are thrown, a stack trace is printed (lines 1422). Regardless of how the thread leaves the try block, it will jump into the finally block and print some information (lines 2330).

After the new thread is spawned, it is given a chance (two seconds) to get to the read() by the main thread (lines 3738). Next, the main thread interrupts the new thread (lines 4042) to see if this has any effect. After another two seconds pass (lines 4445), the main thread takes a harsher approach and tries to stop the new thread (lines 4753). Just in case the thread takes a while to notice, the main thread sleeps for yet another two seconds (lines 5657) before checking again (line 59).


Listing 15.2 shows the output produced when DefiantStream is run. A few seconds after the leaving main() message was printed, I typed the INPUT FROM KEYBOARD line to supply the blocked thread with some data.


Listing 15.2 Output from DefiantStream


1: about to try to read from in

2: about to interrupt thread

3: just interrupted thread

4: about to stop thread

5: just stopped thread, t.isAlive()=false

6: t.isAlive()=false

7: leaving main()

8: --------->INPUT FROM KEYBOARD

9: inside finally:

10: currThread=Thread[Thread-0,5,main]

11: currThread.isAlive()=false

The interrupt() was ignored (lines 23), and quite surprisingly, so was the stop() (lines 45). Notice that isAlive() returns false , but the thread remains blocked on the read() ! Even after the main thread dies (line 7), the blocked thread continues to wait for input. After a few more seconds, I typed line 8 to supply data to the System.in stream. Sure enough, the read() was no longer blocked, and the dead thread printed the last three lines! The somewhat dead thread is able to print that it is not alive (line 11). The thread is somewhat dead in the sense that it returns false from isAlive() , but it continues to execute code! Note that read() probably threw an instance of ThreadDeath (a subclass of Error ) after it got some data, so that only the finally block was executed as the thread shut down.


	Note	The example shows the behavior as of JDK 1.2 on the Win32 platform. As of this writing, there are several bug reports /requests for enhancement (depending on your perspective) pending on these issues. Future releases of the JDK might change this behavior. You can always use DefiantStream to check to see how a particular JavaVM responds.


Toc

Chapter 15 - Breaking Out of a Blocked I/O State