AsynchronousByteCharChannel and Timeouts
cowwoc at bbs.darktech.org
Wed Aug 5 07:17:43 PDT 2009
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.
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.
More information about the nio-discuss