AsynchronousSocketChannel still throws unspecified exception
cowwoc
cowwoc at bbs.darktech.org
Wed Jul 13 09:41:43 PDT 2011
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
More information about the nio-dev
mailing list