AsynchronousSocketChannel still throws unspecified exception

[Alan Bateman]

cowwoc wrote:
> :
> I am fairly sure I am misunderstanding what you wrote above, because it
> seems to contradict our discussion at
> http://web.archiveorange.com/archive/v/gpYtBv5dfSke8QjCflUY
>
> When you say "does not timeout" it means to me "blocks forever until bytes
> come in". But if you read our original discussion (in the above link) "no
> timeout" meant "returns right away if there are no bytes available".
>
> I'm going to break this down again to make sure we understand each other. We
> have:
>
> 1. A read() method
> 2. The actual read operation, let's call it readImpl()
>
> My expectation is that:
> 1. Regardless of what timeout value a user passes into read() it always
> returns right away.
>   
Yep.

> 2. When the user passes a positive timeout value, readImpl() will return any
> available bytes without issuing a read on the underlying file/socket handle.
> If no bytes are available it will issue a read on the underlying file/socket
> handle and wait up to [timeout] milliseconds for bytes to come in before
> throwing a timeout exception.
>   
Reading the "available bytes" requires reading from the socket so a read 
will be initiated. If it completes before the timeout has elapsed then 
the timer will be cancelled.


> 3. When the user passes a timeout <= 0, readImpl() return any available
> bytes (without issuing a read on the underlying file/socket handle). If no
> bytes are available, it will return 0 bytes read.
>
> Now, how does this compare to the actual implementation? What is the current
> behavior?
>   
As it stands, if the timeout is <= 0 then it means there isn't any 
timeout. If there are available bytes or we're at end of stream then the 
read operation will complete immediately (meaning the completion handler 
will be invoked immediately). Otherwise the read will only complete when 
bytes arrive, the peer closes the connection, or some error occurs. This 
is how it is both specified and implemented.

So where we mostly differ is at 3 where I think you are arguing that <= 
0 is a read that is guaranteed to complete immediately. We don't have 
today and would require a bit of consideration to ensure that (a) it is 
actually needed, and (b) what the API would be.

-Alan.