AsynchronousSocketChannel still throws unspecified exception (original) (raw)

Alan Bateman Alan.Bateman at oracle.com
Wed Jul 13 06:40:07 PDT 2011

cowwoc wrote:

: I'm a bit confused. Why does http://download.oracle.com/javase/7/docs/api/java/nio/channels/AsynchronousSocketChannel.html still read "All methods that accept timeout parameters treat values less than or equal to zero to mean that the I/O operation does not timeout"? This looks like the final JDK7 documentation.

To me, "does not timeout" means "waits forever". Is this a simple documentation bug? 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).

:

Fortunately, that's not what I meant. Looking at AsynchronousSocketChannelImpl I am asking for similar handling as "!hasSpaceToRead". If timeout <= 0 and we're returning a Future, set the value immediately and return the Future. If timeout <= 0 and we're returning a CompletionHandler, use Invoker.invoke() to fire an already-computed response. 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).

Does the existing implementation behave this way? Would it be a simple matter to add this? No, it doesn't work this way and would require some consideration before going down that route.

-Alan.

More information about the nio-dev mailing list