Passing exceptions between threads

[shaun82]

I've been trying to setup a thread class that runs for a specific
amount of time, then interrupts the original thread using an exception.

So, here is an example:

SomeRandomClass.class

try {
TimerThread e = new TimerThread();
while(1) {
e.resetTime();
e.start();
<some blocking I/O call>
e.end();
}


} catch(RuntimeException ex) {
// exception caught from TimerThread
}

I was trying to make a TimerThread class which basically acted as a
monitor for a blocking I/O call, and would pull that class out of the
I/O call if it "timed out".

TimerThread is a class which extends Thread, and overrides the run()
method.

It's code went something like this:
TimerThread.class

// overridden from Thread class
void run()
{
while(time_left) { ... }


thrown new RuntimeException("TimerFinished");

}


But of course this does not work, because as soon as the
RuntimeException burns through the TimerThread thread, the TimerThread
instance just dies, and the blocking I/O call continues on its merry
way.

So what do you think of this? Is there anyway for me to salvage this
code? Can I somehow pass the RuntimeException to the original caller of
the TimerThread?

Thanks for any help,
Shaun

 

[tzvika.barenholz]

Perhaps a better idea to achieve the same functionality is to have the
parent thread wait on some object and the child notfify on it.

another idea. make an interface ThreadListenr , and have the parent
class implement it with some notify method. the child thread will be
constructed with a ThreadListenr and call on it the notify when it is
done.

 

[iksrazal]

I've been trying to setup a thread class that runs for a specific
amount of time, then interrupts the original thread using an exception.

You have several options here:

1) Why interrupt via an exception? I solved and posted what seems like
something similair a while back:
http://groups.google.com.br/[email protected]&rnum=6

I used this to time out NIO calls if you are interested in more info.

2) Use Callable from 1.5/5.0 or with 1.4 and below from
EDU.oswego.cs.dl.util.concurrent.* . From the JavaDoc:

The Callable interface is similar to Runnable, in that both are
designed for classes whose instances are potentially executed by
another thread. A Runnable, however, does not return a result and
cannot throw a checked exception.

HTH,
iksrazal
http://www.braziloutsource.com/

 

[Esmond Pitt]

I've been trying to setup a thread class that runs for a specific
amount of time, then interrupts the original thread using an exception.

So, here is an example:

SomeRandomClass.class

try {
TimerThread e = new TimerThread();
while(1) {
e.resetTime();
e.start();
<some blocking I/O call>
e.end();
}


} catch(RuntimeException ex) {
// exception caught from TimerThread
}

I was trying to make a TimerThread class which basically acted as a
monitor for a blocking I/O call, and would pull that class out of the
I/O call if it "timed out".

TimerThread is a class which extends Thread, and overrides the run()
method.

It's code went something like this:
TimerThread.class

// overridden from Thread class
void run()
{
while(time_left) { ... }


thrown new RuntimeException("TimerFinished");

}


But of course this does not work, because as soon as the
RuntimeException burns through the TimerThread thread, the TimerThread
instance just dies, and the blocking I/O call continues on its merry
way.

So what do you think of this? Is there anyway for me to salvage this
code? Can I somehow pass the RuntimeException to the original caller of
the TimerThread?

What is the blocking I/O call doing that it needs to be interrupted? If
it is reading or writing a file it's not going to block for long enough
to be a problem. If it's connecting to a port, use a connect timeout. If
it's reading a COM port or a socket, use a read timeout. If it's writing
to a COM port, use a write timeout if there is such a thing, or async
I/O. If it's writing to a socket and the receiver is slow, speed up the
receiver, use larger socket buffers, change your application protocol so
you don't write more than you know the receiver is ready for at a time,
or use NIO.