AsynchronousSocketChannel still throws unspecified exception

Alan Bateman Alan.Bateman at oracle.com
Wed Jul 13 10:34:47 PDT 2011


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

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

-Alan.


More information about the nio-dev mailing list