AsynchronousSocketChannel still throws unspecified exception

[cowwoc]

Alan Bateman-2 wrote:
> 
> The read/write operations in this API are asynchronous. They are not 
> synchronous and do not wait, irrespective of the timeout values. So when 
> it says "does not timeout" it just means that the I/O operations do not 
> have an associated timeout. If you invoke the read/write methods then 
> the methods will complete immediately but the I/O operation will only 
> complete when bytes are actually read or written (so exactly the same as 
> the read/write methods that AsynchronousByteChannel defines).
> 

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.
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.
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?


Alan Bateman-2 wrote:
> 
> This requires a result, which is why I suggested it would require 
> polling the socket and if not readable (or writable, depending) then the 
> I/O operation would complete with a result of 0 (which is essentially an 
> asynchronous equivalent of synchronous read/write with the channel 
> configured non-blocking).
> 

I understand.

Thank you,
Gili

--
View this message in context: http://nio-dev.3157472.n2.nabble.com/AsynchronousSocketChannel-still-throws-unspecified-exception-tp6471557p6579342.html
Sent from the nio-dev mailing list archive at Nabble.com.