AsynchronousSocketChannel still throws unspecified exception

[cowwoc]

On 13/07/2011 1:34 PM, Alan Bateman wrote:
> cowwoc wrote:
>> :
>>     Okay, but this contradicts our original discussion and how j.u.c 
>> works (which we're trying to be consistent with). I'll give you a 
>> simple example. If I invoke CountDownLatch.await(0, 
>> TimeUnit.MILLISECONDS) the specification reads "If the current count 
>> is zero then this method returns immediately." So first of all we've 
>> established that a timeout of zero should never block.
> This is a wait timeout, meaning that CountDownLatch.await will 
> block/wait when a timeout is specified (assuming the latch hasn't 
> counted down). So if this were a synchronous I/O API then all would be 
> clear.
>
> With an asynchronous I/O API then the read/write methods never 
> block/wait. The timeout is instead associated with the I/O operation 
> to support error handling in the event that the peer does not respond. 
> The > 0 case should be clear, the <= 0 is less clear and is currently 
> specified (and implemented) to work like the read/write methods that 
> doesn't have timeout parameters. Translating this into synchronous 
> terms then it's equivalent to await().

     I don't see why the <= 0 case is less clear. The way I see it, 
read() is an asynchronous layer on top of a synchronous readImpl() API. 
If we're saying that timeout <= 0 means "return immediately" then surely 
readImpl(timeout<=0) should return right away. read() isn't part of the 
equation because (as we both agree) the timeouts are really parameters 
for readImpl(), not read().

>>     I understand but I expect this to work similar to 
>> ReentrantLock.tryLock(0, TimeUnit). If available() >= 0 then it 
>> should return all available bytes immediately regardless of what the 
>> timeout value is. I believe you simply need to invoke available() 
>> before beginning a read. If it returns a non-zero value, disable the 
>> timeout and read forever (the OS guarantees this should return 
>> instantaneously).
> For socket I/O (AsynchronousSocketChannel) this would be expensive. I 
> think what we need to establish is whether this is really needed, and 
> if so, what is the API. Possible API approaches would be a channel 
> mode (configureImmediateMode/equivalent), new readNow/writeNow 
> methods, or even an "available" method.

     I think it's needed for the reasons I mentioned here: 
http://nio-dev.3157472.n2.nabble.com/AsynchronousSocketChannel-still-throws-unspecified-exception-tp6471557p6579825.html

     I'm against adding a separate method (instead of timeout of zero 
meaning "return immediately") because:

1. It won't be consistent with java.util.concurrent
2. It causes problems when users compose timeouts:

  void composite(timeLimit) {
       ...
       step1(timeLimit);
       ...
       step2(timeLimit - elapsed);
    }

if (timeLimit - elapsed) happens to be <= 0 all of a sudden the call 
blocks forever instead of waiting the remaining amount of time.

Gili