AsynchronousByteCharChannel and Timeouts

[Alan Bateman]

cowwoc wrote:
> :
> 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.
>   
The wording in the "Cancellation" section of AsynchronousChannel, and 
the "Timeouts" section of AsynchronousSocketChannel, do make it clear 
that they are specifying behavior for implementations where cancellation 
leaves the entity to which the channel is connected in an inconsistent 
state. So nothing should prohibit you from creating an implementation 
where you can continue to use the channel after cancellation. I'll 
create a bug to track this and we can see if we can improve the wording.

>
> :
> 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.
>   
The intended behavior is that a read operation completes when some bytes 
(up to r) are read. The result of the operation is the number of bytes 
read. It just wouldn't be useful otherwise as there are many protocols 
where you don't know the number of bytes in advance.
>
> :
> 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.
>   
The extra burden is that it would require every implementation to 
include support for timeouts.

-Alan.