Closing inputstream while read in progress - no error?

[Rogan Dawes]

Hi folks,

While trying to figure out a solution to the "read console with timeout"
problem posed on this group, I encountered an interesting situation.

I have one thread blocking in a readLine() on a Reader (a BufferedReader
wrapping an InputStreamReader wrapping System.in).

In another thread, I close the reader, expecting the blocking readLine()
to throw an exception. But it didn't.

Would it not make sense for a blocking read to throw an exception if the
stream/reader is closed while the read is blocking? I guess one can just
say "don't access the reader from multiple threads", like the Swing EDT
rule, but it seems a bit arbitrary in this case.

Regards,

Rogan

 

[Chris Uppal]

I have one thread blocking in a readLine() on a Reader (a BufferedReader
wrapping an InputStreamReader wrapping System.in).

In another thread, I close the reader, expecting the blocking readLine()
to throw an exception. But it didn't.

It seems a little odd, I agree. Especially since
System.in.close();
/does/ work as expected. It seems to be because the underlying
InputStreamReader (and its pet sun.nio.cs.StreamDecoder) holds a lock while it
is blocking on a read(), and the attempt to close() the stream also attempts to
acquire that lock. Hence it is blocked until the read() returns. Which seems
more than a little strange to me...

Incidentally, I've changed my mind, and I now think the original problem is
solvable -- you have to have one thread dedicated to reading System.in which
transfers the data over some kind of queue to the real processing. It doesn't
ever time out a read, but the attempt to pull data from the queue can be timed
out. Each time you ask a new question you should probably flush the queue
(although that won't flush typeahead characters that are still owned by the
OS).

-- chris

 

[Rogan Dawes]

It seems a little odd, I agree. Especially since
System.in.close();
/does/ work as expected. It seems to be because the underlying
InputStreamReader (and its pet sun.nio.cs.StreamDecoder) holds a lock while it
is blocking on a read(), and the attempt to close() the stream also attempts to
acquire that lock. Hence it is blocked until the read() returns. Which seems
more than a little strange to me...

Incidentally, I've changed my mind, and I now think the original problem is
solvable -- you have to have one thread dedicated to reading System.in which
transfers the data over some kind of queue to the real processing. It doesn't
ever time out a read, but the attempt to pull data from the queue can be timed
out. Each time you ask a new question you should probably flush the queue
(although that won't flush typeahead characters that are still owned by the
OS).

-- chris

Well spotted.

I had "instrumented" my interrupting thread, and had assumed that the
close() was successful. I never realised that the close() was not
returning until I added a second println afterwards.

Rogan