hg: nio/nio/jdk: First installation of potential updates for M4

[Alan Bateman]

Alexander Libman wrote:
>> No, it shouldn't interfere with other I/O operations. For example on a
>> channel to a stream socket then you might cancel a read and this should
>> not interfere with a concurrent write. In this case the cancel may not
>> be able to guarantee that bytes have not been transferred so this will
>> prevent further reads on the channel (but it should not impact writing).
>>
>>     
>
> Very clear.  May be couple lines from above paragraph would be nice to see
> in javadoc.
>   
OK,  I'll see if I can add wording to make this clearer.

> :
> I was thinking about such solution earlier. It will work fine only with one
> condition:
> user must discard buffers used in cancelled operation.
> I wanted avoid discarding buffers  and provide the following guarantee at
> least in filters:
> If a completion is delivered (exception/result  or  the moment of invocation
> the completion handler), then
> the developer can reuse buffers for the finished operation.
>   
There is a paragraph in the cancellation section that recommends that 
the buffers be discarded or "care taken to ensure that the buffers are 
not accessed while the channel remains open". Cancellation will be 
rarely used, if ever, so either approach should be okay. On the other 
hand, cancellation will be frequently used as timeouts in 
AsynchronousSocketChannel. In that case the I/O operation will fail with 
InterrupedByTimeoutException. If the application decides not to close 
the channel immediately then it will need to discard the buffer or 
ensure that it doesn't re-use it until the channel is closed. The 
timeout case might not be a concern for your filters package.

> :
> If discarding buffers is required only for cancelled operations and not for
> all other failures, I would be also OK.
>   
Cancellation and timeouts (which is essentially a type of cancellation) 
are the only two cases where you must take care not to access the 
buffers until the channel is closed.


> Good. I asked because it allows to implement non-cancellable  cancel()
> without discarding buffers in form
>
> cancel (boolean mayInterruptIfRunning)
> {
>     if (! mayInterruptIfRunning) {
>          try  {
>               this.get();
>          }
>          catch (Exception e)
>          {}
>
>          return isCancelled();  // actually always returns false
>     }
>     ....
> }
>   
My understanding is that Future#cancel was not intended to block 
indefinitely like this (it can't throw InterruptedException for 
example). Since cancel can't do anything in this case it should be fine 
to just return true (assuming it hasn't already completed or cancelled) 
as the application is saying that it is no longer interested in the result.

-Alan.