AsynchronousSocketChannel still throws unspecified exception

[cowwoc]

On 13/07/2011 11:51 AM, Alan Bateman wrote:
>> 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?
> As it stands, if the timeout is <= 0 then it means there isn't any 
> timeout. If there are available bytes or we're at end of stream then 
> the read operation will complete immediately (meaning the completion 
> handler will be invoked immediately). Otherwise the read will only 
> complete when bytes arrive, the peer closes the connection, or some 
> error occurs. This is how it is both specified and implemented.
>
> So where we mostly differ is at 3 where I think you are arguing that 
> <= 0 is a read that is guaranteed to complete immediately. We don't 
> have today and would require a bit of consideration to ensure that (a) 
> it is actually needed, and (b) what the API would be.

     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.

     The next example demonstrates how a timeout of zero can be used to 
poll a value. If I invoke ReentrantLock.tryLock(0, 
TimeUnit.MILLISECONDS) it tries acquiring the lock without waiting. If 
the lock is not immediately available, it returns false. If it is 
immediately available, it establishes the lock and returns true. That's 
my interpretation based on 
http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/ReentrantLock.html#tryLock%28%29  
's discussion of "if you want to honor the fairness setting for this lock".

> Reading the "available bytes" requires reading from the socket so a 
> read will be initiated. If it completes before the timeout has elapsed 
> then the timer will be cancelled.

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

Gili