AsynchronousByteCharChannel and Timeouts

[Alan Bateman]

cowwoc wrote:
> :
>     I don't think that it is safe to assume that timeouts are a form 
> of execution error. When I asked about timeouts on the RXTX mailing 
> list a lot of people responded that they expect to be able to use the 
> channel after a read() timeout. For example, some comport protocols 
> "frame" data packets using a timeout. So you read() and if a timeout 
> occurs you assume that the *next* read denotes a new packet or 
> connection. In such a case, you do not want to close and reopen the 
> comport because you might miss some bytes.
>
>     I think it is perfectly reasonable for some channel 
> implementations to invalidate after a timeout, if this is the 
> exception to the rule. What worries me is that you seem to be implying 
> the opposite: that more-often-than-not a timeout error should result 
> in the channel in an undefined state.
>
>     For some category of channels, such as comports, an implementation 
> that invalidates after a timeout is fairly useless.
AsynchronousSocketChannel is intended to represent a connection to a 
reliable stream. Applications using the channel are not expected to 
tolerate data loss or data repetition in the stream. That paragraph on 
timeouts is just saying that if, on timeout, that the implementation 
cannot guarantee that bytes haven't been (or won't be) transferred then 
it should prevent further I/O of that type on the channel. Also remember 
the channel may have very different implementations, depending on the 
operating system and I/O facility used. If implemented using blocking or 
asynchronous I/O (for example) then it may be completely unfeasible to 
cancel the I/O operation cleanly when the timer has expired. On the 
other hand, there will be implementations (non-blocking based in 
particular) where a timer can safely "cancel" with the guarantee that no 
bytes have been transferred. In those cases, the channel can of course 
be re-used. I can't say if this approach is completely suitable for your 
serial port channel but it does seem like the timeout (or the Future 
cancel if that style is used) will need to be able to cause the 
underlying I/O to be cancelled.

-Alan.