Timeout values

[Gili]

Did this message ever get accepted by the mailing list? I ask because
http://n2.nabble.com/Timeout-values-td3093833.html seems to believe
otherwise.

Thanks,
Gili


Gili wrote:
> 
> 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-tp3093833p3158082.html
Sent from the nio-discuss mailing list archive at Nabble.com.