views:

115

answers:

2

I'm using RXTX to read data from a serial port. The reading is done within a thread spawned in the following manner:

CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(port);
CommPort comm = portIdentifier.open("Whatever", 2000);
SerialPort serial = (SerialPort)comm;
...settings
Thread t = new Thread(new SerialReader(serial.getInputStream()));
t.start();

The SerialReader class implements Runnable and just loops indefinitely, reading from the port and constructing the data into useful packages before sending it off to other applications. However, I've reduced it down to the following simplicity:

public void run() {
  ReadableByteChannel byteChan = Channels.newChannel(in); //in = InputStream passed to SerialReader
  ByteBuffer buffer = ByteBuffer.allocate(100);
  while (true) {
    try {
      byteChan.read(buffer);
    } catch (Exception e) {
      System.out.println(e);
    }
  }
}

When a user clicks a stop button, the following functionality fires that should in theory close the input stream and break out of the blocking byteChan.read(buffer) call. The code is as follows:

public void stop() {
  t.interrupt();
  serial.close();
}

However, when I run this code, I never get a ClosedByInterruptException, which SHOULD fire once the input stream closes. Furthermore, the execution blocks on the call to serial.close() -- because the underlying input stream is still blocking on the read call. I've tried replacing the interrupt call with byteChan.close(), which should then cause an AsynchronousCloseException, however, I'm getting the same results.

Any help on what I'm missing would be greatly appreciated.

+1  A: 
erickson
In my example, Channels.newChannel(<input stream>) returns an object of type ReadableByteChannelImpl, which implements ReadableByteChannel (but more importantly extends AbstractInterruptibleChannel which implements InterruptibleChannel).
JDS
Oops...enter submits the comment.Anyways, doing an instanceof check for byteChan against InterruptibleChannel returns true. Also, since it wasn't clear, the call to stop() is done in the thread that spawns the reading loop thread.
JDS
@JDS - … and yet, it doesn't work, does it? Please see my update. The channel is not interruptible, and you may have no viable option for bailing out of an RXTX read.
erickson
A: 

The RXTX SerialInputStream (what is returned by the serial.getInputStream() call) supports a timeout scheme that ended up solving all my problems. Adding the following before creating the new SerialReader object causes the reads to no longer block indefinitely:

serial.enableReceiveTimeout(1000);

Within the SerialReader object, I had to change a few things around to read directly from the InputStream instead of creating the ReadableByteChannel, but now, I can stop and restart the reader without issue.

JDS