Timeout values

[Alan Bateman]

Doug Lea wrote:
> :
> BTW, besides conforming to common sense, the main reason for this is
> to make waits composable. As in:
>   void composite(timeLimit) {
>      ...
>      step1(timeLimit);
>      ...
>      step2(timeLimit - elapsed);
>   }
> which otherwise can surprisingly misbehave if timeLimit - elapsed
> happens to be 0.
That is a useful property - thanks!

> :
> It was done this way in nio because the above arguments were
> not enough to convince those people accustomed to C select/poll
> APIs, especially since TimeUnit had not yet been introduced,
> and without it there was no good alternative convention to point to.
Although I don't think it carried over completely in that a negative 
value to poll usually means an indefinite wait. In any case, we need to 
watch for further APIs bringing timeouts to make sure that 
inconsistencies don't creep in. It's a pity we can't do anything with 
the existing APIs.

>
>>
>> whereas if you want a timeout then you will use the 5-parameter methods:
>>  read(ByteBuffer, long, TimeUnit, Object, CompletionHandler)
>>
>> Your concern is with 5-parameter methods for cases where you don't 
>> want a timer. This usage will likely be rare (except for the 
>> scatter/gather case which don't have overloading for all cases). As 
>> specified now, you pass a timeout of 0L  to mean "no timeout". 
>
> I agree that this should be changed. Any method taking a TimeUnit
> should obey j.u.c conventions. Which means separating out the
> no-timeout case as another method. Which would be a minor
> nuisance to carry out but will probably result in fewer
> usage errors.
I'll fix this shortly so that <= 0 means no-timeout. It's a minor change 
but if it does result in fewer usage errors, as you suggest, then it's 
definitely worth it.  Thanks for jumping in to make sure we get this right.

-Alan.