AsynchronousSocketChannel still throws unspecified exception

[cowwoc]

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