Timeout values

[Gili]

Hi,

Alan and I discussed NIO2 timeout values a few weeks ago. I wanted to
continue this discussion in a more public forum. Here is what was said so
far:

Gili wrote:
> On a separate note, I believe there is inconsistency between
> AsynchronousSocketChannel's definition
> of timeouts (where timeout==0 means "no timeout") and
> http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html
> that states "All methods that accept timeout parameters treat values less
> than or equal to zero to
> mean not to wait at all. To wait "forever", you can use a value of
> Long.MAX_VALUE." 
> 
> nio2 "timeout == 0" is equivalent to concurrent "timeout ==
> Integer.MAXIMUM" and
> concurrent "timeout == 0" has no equivalent in nio2. Although nio2's
> definition feels more familiar
> coming from a C/C++ background, I personally prefer the concurrent
> definition.

Alan wrote:
> You are right that the concurrent and channels package aren't consistent
> here but I don't see that we
> have an inconsistency in the channels package.
> 
> In the concurrent package then a timeout of <=0 means do not wait. In the
> channels package then 0
> means wait forever and <0 is invalid (when I say the channels package I
> means Selector#select as
> that is the only blocking method with timeout in that package). This
> inconsistency has been there for
> several releases and hasn't been a major problem (to my knowledge anyway).
> 
> With the asynchronous I/O API the operations are non-blocking so there is
> no equivalent to "do not
> wait" in this API. Instead, the I/O operation has an associated timer or
> it doesn't. That plus we have
> tried to be consistent with Selector we have timeout == 0 means no timer
> and <0 is invalid. Clearly we 
> are open to better ways to doing this. For example, one could argument
> that <= 0 should mean no 
> timer but that would be inconsistent with Selector. One could argue that
> Long.MAX_VALUE should 
> mean infinitely but that just makes it more awkward to use when you don't
> want a timeout.

Wanting to maintain backwards compatibility with Selector is perfectly
valid, and I fully appreciate the fact that the asynchronous I/O APIs
probably have no need for "do not wait" but I personally believe that it is
very important for timeouts usage to be consistent across all the Core APIs.
Users should be able to transition from one API to another without having to
read the fine print about how timeout works in this package or another.

As to the argument that using Long.MAX_VALUE is more awkward than zero, I
think it's subjective. On an equally subjective level, I personally find "0
means do not wait, Long.MAX_VALUE means wait forever" a lot more intuitive
than the Selector behavior.

I'd love to hear what others on this forum think on the matter.

Thanks,
Gili
-- 
View this message in context: http://n2.nabble.com/Timeout-values-tp3093833p3093833.html
Sent from the nio-discuss mailing list archive at Nabble.com.