AsynchronousByteCharChannel and Timeouts

[Gili]

Alan Bateman wrote:
> 
> 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.
> 

Okay. I agree with everything you wrote except for the earlier post about
how it should be possible to implement read-with-timeout in terms of
read-forever. For the win32 comport API at least this doesn't seem to be
possible. How does it work for sockets?

If you start a read for 10 bytes and a Timer tells you about a timeout after
you only read 5 bytes are you saying you can tell the underlying OS to stop
reading but also give you whatever data it already read? As I mentioned
before, the OS lets me stop ongoing reads for serial ports but then it will
queue any read data and I can only get at it if I try to read() again.

Gili
-- 
View this message in context: http://n2.nabble.com/AsynchronousByteCharChannel-and-Timeouts-tp3363004p3392148.html
Sent from the nio-discuss mailing list archive at Nabble.com.