AsynchronousByteCharChannel and Timeouts

[cowwoc]

Alan Bateman-2 wrote:
> 
> cowwoc wrote:
>> Put it another way: how would you implement an efficient
>> read-with-timeout on
>> top of the current AsynchronousByteChannel interface? Alternatively, how
>> would you implement read-with-timeout on top of an OS that only supports
>> read-forever?
>>
>> I'm not looking for a full-fledged implementation. Just tell me what you
>> would do conceptually.
>>   
> I'm not sure that I have all the context here. When you say that the OS 
> only supports read-forever then it sounds like you are implementing 
> AsynchronousByteChannel via blocking operations - is that right? If so, 
> then you could use a ScheduledThreadExecutor to implement the timeout. 
> The issue then becomes what to do with the thread that is blocked doing 
> the I/O. Do you have a means to cancel/interrupt it? At least with 
> socket channels, then the channel will typically be closed if there is a 
> timeout because the peer is not responding.
> 


Hi Alan,


The Context
------------

I'm trying to implement AsynchronousByteCharChannel in an
implementation-independent manner so that you can feed in any
AsynchronousByteChannel. Now, in light of the fact that
AsynchronousByteChannel does not talk about timeouts, nor can
AsynchronousByteCharChannel. Eventually, though, my application needs to be
able to read-with-timeout from an underlying serial port. This forces me to
implement read-with-timeout on top of an interface that only provides
read-forever.

AsynchronousSocketChannel's Javadoc reads "A timeout may leave the channel,
or the underlying connection, in an inconsistent state. Where the
implementation cannot guarantee that bytes have not been read from the
channel then it puts the channel into an implementation specific error
state." but for serial ports, a timeout does *not* leave them in an
inconsistent state so the question becomes: how can I continue using the
channel after a timeout?

I am arguing that although the specification says that a timeout *may*
result in an inconsistent state, it makes it impractical to do otherwise.

Specific Problems
-----------------

Say I want to implement read-with-timeout on top of a read-forever
implementation. A user invokes:
readWithTimeout(n=10) followed by
readWithTimeout(n=5)

Given a AsynchronousByteChannel that initially has 9 bytes buffered. When
the user invokes readWithTimeout(n=10) the specification does not guarantee
that read() will return 9 bytes without blocking. Because I cannot safely
assume the implementation must return immediately once it receives at least
one byte I must invoke AsynchronousByteChannel.read(n=1). Consider what
would happen if I did not: If I issued AsynchronousByteChannel.read(n=10)
and the call blocked indefinitely, the first user call would result in a
timeout. The user would then issue readWithTimeout(n=5). Now, technically
speaking the underlying AsynchronousByteChannel has sufficient bytes to
return right away, but practically speaking it is blocked trying to read 10
bytes so I end up blocked for no reason.

So point #1: Perhaps the specification should require implementations to
return immediately if it can return at least one byte.


My second argument is that we would be better off if AsynchronousByteChannel
only contained read-with-timeout methods as opposed to placing read-forever
in AsynchronousByteChannel and adding read-with-timeout in
AsynchronousSocketChannel. I argue that it's always easier and more
efficient to implement read-forever on top of read-with-timeout than the
opposite. I think the fact that we only have one kind of
AsynchronousByteChannel subclass (for sockets) prevents us from properly
validating that the design makes sense for different kinds of devices.

I would like to hear your thoughts on this. Hopefully there is a simple
solution I am overlooking :)

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