How to tell a Thread to quit if the Thread is blocking on IO?

[metfan]

Hi,

I created a thread and in the run() method the thread will
read from a BufferedReader(). If there are no data available
for read, the thread blocks. Now how can I tell the blocking
thread to quit from run() in another thread?

 

[ak]

I am not sure, but you could try to interrupt it (first set some flag that
thread must exit):

boolean finished;

void run() {
while(!finished) {
in.read();
}
}

void finish() {
finished = true;
}

much better if you use available() to check if next read call blocks.

void run() {
while(!finished) {
if(int cnt = in.available() > 0) {
byte b [] = new byte[cnt];
in.read(b);
}
else {
try {
Thread.sleep(100);
}
catch(InterruptedException) {
finished = true;
}
}
}
}

void finish() {
finished = true;
}

Regards

Andrei

 

[Michael Borgwardt]

Hi,

I created a thread and in the run() method the thread will
read from a BufferedReader(). If there are no data available
for read, the thread blocks. Now how can I tell the blocking
thread to quit from run() in another thread?

Close the stream on which the thread is blocking, it will then
fail with an IOException.

 

[Mark Thornton]

Close the stream on which the thread is blocking, it will then
fail with an IOException.

On the other hand it may not. I think this behaviour is system dependent.

Mark Thornton

 

[Gordon Beaton]

much better if you use available() to check if next read call blocks.

No, it's not.

First, your solution will have pathetic performance when you have a
lot of data to read, because every once in a while there will be a
short gap in the data that causes you to sleep. Choosing a suitable
delay here is difficult, because you have to trade performance against
cpu load.

Second, detecting EOF is difficult when available() is involved. It
returns 0 when there is no data currently available, but also when the
connection is closed. You need to read() to see the difference, and
that brings you back to the initial problem.

If the data is being read from a SocketInputStream, a read timeout can
be used to prevent read() from blocking indefinitely. At that point,
the "finished" flag can be tested.

/gordon

 

[Michael Borgwardt]

I am not sure, but you could try to interrupt it (first set some flag that
thread must exit):

boolean finished;

void run() {
while(!finished) {
in.read();
}
}

void finish() {
finished = true;
}

This is of course completely useless if the threas is blocked
on the IO call.

much better if you use available() to check if next read call blocks.

void run() {
while(!finished) {
if(int cnt = in.available() > 0) {
byte b [] = new byte[cnt];
in.read(b);
}
else {
try {
Thread.sleep(100);
}
catch(InterruptedException) {
finished = true;
}
}
}
}

Works, but will lead to absolutely horrible performance or a completel failure
to read anything, depending on the input stream implementation.

 

[Michael Borgwardt]

On the other hand it may not. I think this behaviour is system dependent.

Since it doesn't seep to be specified, that might indeed be the case, but
it should be consistent on each system.

The only really clean solution seem to be the java.nio classes of Java 1.4,
where interruption is a specified behaviour.

 

[Mark Thornton]

Since it doesn't seep to be specified, that might indeed be the case, but
it should be consistent on each system.

The only really clean solution seem to be the java.nio classes of Java 1.4,
where interruption is a specified behaviour.

http://developer.java.sun.com/developer/bugParade/bugs/4154947.html
http://developer.java.sun.com/developer/bugParade/bugs/4344135.html

Mark Thornton

 

[Raymond DeCampo]

Since it doesn't seep to be specified, that might indeed be the case, but
it should be consistent on each system.

The only really clean solution seem to be the java.nio classes of Java 1.4,
where interruption is a specified behaviour.

Do you mean to imply that interrupting the thread via Thread.interrupt()
would not work under traditional I/O? This is not what I would expect.
Or perhaps you mean something else by "clean solution". Could you
clarify?

Ray

 

[Mark Thornton]

Do you mean to imply that interrupting the thread via Thread.interrupt()
would not work under traditional I/O? This is not what I would expect.
Or perhaps you mean something else by "clean solution". Could you
clarify?

Correct. Interruptible I/O has never been properly implemented. It is
apparently impossible to implement satisfactorily on Windows (at least
Sun have given up trying).

Mark Thornton