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

[Alan Bateman]

libman at terabit.com.au wrote:
> Alan,
> Please correct me, if I am  wrong.
> Or may be my questions will help to fix doc:
>
> from AsynchronousChannel doc
> --------------------------------
> Cancellation
>
> The Future interface defines the cancel method to cancel execution of a task.
>
> Where the cancel method is invoked with the mayInterruptIfRunning
> parameter set to true then the I/O operation may be interrupted by closing
> the channel. This will cause any other I/O operations outstanding on the
> channel to complete with the exception AsynchronousCloseException.
> -----------------------------------------------------------------------
>
> So if mayInterruptIfRunning is true, what exception should be generated
> for given operation:  Cancellation Exception or AsynchronousCloseException
> or any of them is legal? I assumed that any of them is legal.
> That is why you misunderstood me.
> If my assumption is wrong, probably it would be good to state
> explicitly in doc that given operation should finish with
> only CancellationException.
>   
When the Future's cancel method is invoked then any thread waiting for 
the result of that I/O operations throws CancellationException (ie: it's 
the Future's get method that throws this exception).

The second sentence in the above paragraph is specifying the impact on 
*other* I/O operations for the case that the forceful cancel is 
implemented as an asynchronous close. So if there are other I/O 
operations in progress then they complete (fail) with 
AsynchronousCloseException. How that AsynchronousCloseException is 
delivered depends on how the I/O operation was specified. If initially 
specifying a completion handler then the handler's failed method is 
invoked with this exception. If initiated, returning a Future then the 
Future's get method throws ExecutionException with cause 
AsynchronousCloseException.

Does that make sense? Maybe it is possible to re-word this to make it 
clearer but the important thing is that relates to the impact on other 
I/O operations that might be progress at the time of a forceful cancel.

>
> from Future doc
> --------------------------------
> This attempt will fail if the task :
> has already completed,
> has already been cancelled,
> or could not be cancelled for some other reason
>
> Assuming that cancel(true) can produce  AsynchronousCloseException,
> my example is legal:
>
> cancel (boolean mayInterrupt)
> {
>    if (mayInterrupt) {
>        // this will force all operations
>        // including this operation
>        // fail with  AsynchronousCloseException.
>        // So operation failed, but not cancelled
>        channel.close();
>     }
>     else {
>        // we can not cancel opeartion
>        //  "for some other reason"
>     }
>     return false;
> }
>   
I don't think this will work. The spec requires that after cancel is 
invoked then subsequent calls to isDone and isCancelled must return 
true. So in the above you must return true (assuming ithe I/O operation 
has not completed or has not already been cancelled).

-Alan.