AsynchronousByteCharChannel and Timeouts

[cowwoc]

Alan Bateman-2 wrote:
> 
>> I am arguing that although the specification says that a timeout *may*
>> result in an inconsistent state, it makes it impractical to do otherwise.
>>   
> Do you have  a suggestion for how it could specified otherwise? 
> Cancellation (be it by timeout, or invoking the Future's cancel method) 
> is an awkward topic. We can't assume that the underlying I/O operation 
> can be cancelled cleanly as it is highly operating system/implementation 
> specific.
> 

Making the spec more explicit (as mentioned in the point directly below)
would make it more practical to implement channels that do not get
invalidated after a timeout.


Alan Bateman-2 wrote:
> 
>> So point #1: Perhaps the specification should require implementations to
>> return immediately if it can return at least one byte.
>>   
> In this example the first read should complete immediately having read 9 
> bytes. Maybe we need to make this clearer in the spec, but in summary, 
> if you initiate a read with a buffer that has r bytes remaining in the 
> buffer, then read will complete having read up to r bytes. There should 
> be no expectation that the read doesn't complete until r bytes have been 
> read.
> 

Please make this explicit in the spec.


Alan Bateman-2 wrote:
> 
> Also just to clarify one thing - the read (and write) methods in this 
> API are non-blocking (just mentioning this as your talk about blocking 
> indefinitely).
> 

I know. What I meant is that if a user invokes:

readWithTimeout(n=10)
readWithTimeout(n=5)

If the underlying implementation is read-forever and we do not wish to
invalidate the channel on the first timeout then we must allow the
underlying read to continue. When the user invokes the second
readWithTimeout() we notice that the underlying read is still pending so we
wait on it to complete (that is, we do not invoke read() a second time).
While it is true that the user thread doesn't block, the channel
implementation will end up waiting/"blocking" on a read() from a previous
invocation. By making the spec more explicit on the above point we can at
least guarantee that the implementation will not end up blocking longer than
it has to.

Without the spec refinement I can only (safely) read 1 byte at a time. With
the spec refinement I can safely read 10 bytes when readWithTimeout(n=10)
gets invoked knowing that if I'm still blocked on the read when the
readWithTimeout(n=5) comes in it must mean that I don't have 5 bytes
available. That is, I am blocking for a good reason.


Alan Bateman-2 wrote:
> 
>> 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.
>>   
> There may be merit in this although it increases the burden on the 
> implementor

How does this (substantially) increase the burden on the implementer? I
assume you're not talking about the extra burden of implementing
read-forever on top of read-with-timeout because this just requires you to
wrap your existing code with a single while() loop.


Alan Bateman-2 wrote:
> and the only channel in this API that could implement it is 
> AsynchronouSocketChannel.

AsynchronousSerialChannel would implement it. I'm sure there are other
devices that would fit naturally on top of this excellent API. I suspect all
commercial users of asynchronous channels will be timeout-driven. Infinite
timeout only makes sense for non-blocking streams (i.e. files) or "Hello
World" examples. I don't see it being used in any commercial-grade
socket/serial/etc applications.

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