AsynchronousSocketChannel still throws unspecified exception (original) (raw)

cowwoc cowwoc at bbs.darktech.org
Wed Jul 13 05🔞20 PDT 2011

Alan Bateman-2 wrote:

cowwoc wrote: : Now I'm getting really worried... I just noticed that socket timeouts are wrong as well!

If you recall, we had agreed that a timeout value of 0 or less should mean "no timeout" and Long.MAXVALUE should mean "wait forever": http://web.archiveorange.com/archive/v/gpYtBv5dfSke8QjCflUY Yes, I remember that discussion and we changed it, via 6878369, so that <= 0 means that the I/O operation doesn't have a timeout (previously it was specified to throw IllegalArgumentException if a negative timeout was specified). -Alan.

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?

Alan Bateman-2 wrote:

Just to clarify, the methods that take a timeout do not wait. They are asynchronous like the other read/write methods and it's just a case that the I/O operations may have an associated timeout. If I understand your most recent mails then what you are asking for a way to read/write where the I/O operation is guaranteed to complete immediately, an asynchronous equivalent to a synchronous read/write where the channel is configured non-blocking. This would require a bit of consideration. It would clearly be more expensive, at least for implementations where the underlying I/O is blocking or asynchronous as such implementations would need to first poll the socket. An alternative, at least for the read case, is an "available" method.

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.

Does the existing implementation behave this way? Would it be a simple matter to add this?

Thanks, Gili

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

More information about the nio-dev mailing list