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

[Alan Bateman]

Alexander Libman wrote:
> :
> I am thinking  about  real  use case of cancel() and can not find a good
> example..
> If cancel()  returns true, but  leaves channel in unspecified state and all
> you can do is
> only close the channel.
>
> Assuming that  we manage to cancel read for streams/sockets,
> then it does not mean that we can receive different data for another read.
> Cancel may be usefull only for regular files. But also hard to find an
> example.
>
> For the filters, we can cancel operation and leave channel in consistent
> state,
> only if buffers were not modified. To do this we have to maintain Future
> state:
> RUNNING, PENDING, COMPLETED, FAILED, CANCELLED
> Basically,  3 last states are substates of DONE.
> RUNNING means operation is active, i.e. filter works with buffers and
> PENDING means that operation is cancellable,i.e. filter currently does not
> work with buffers.
> State is AtomicInteger .
>
> I think similar mechanizm used in NIO2.
>
> But support of cancel() makes code much more complicated
> The quiestion: does it make sense to implement cancellation of particular
> operation ?
>   
Cancellation is usually not interesting or does not make sense for I/O 
but there are people that seem to care. I have not come across any cases 
where a cancel isn't quickly followed by a close. The spec does allow 
for cases where it is feasible to cancel individual I/O operations but 
mandates that subsequent operations are only allowed on the channel if 
the cancellation leaves the channel and connection is a consistent 
state. As I'm sure you understand this is important for stream protocols 
as otherwise you risk introducing very hard to debug protocol errors at 
the higher level (like the interruptible I/O mess in early releases).

> Currently, I believe that the following implementation will be enough (sorry
> for repetition):
>
> cancel (boolean mayInterrupt)
> {
> 	if (mayInterrupt) {
> 		channel.close();
> 	}
> 	return false;
> }
>
> In other words, cancel is always NOOP if mayInterrupt is false and
> otherwise hidden form of close() via Future method.
> And this implementation complies to the specification.
>
> May be it does make sense to declare cancel()   strictly in such way and
> forget about pain with
> cancellation of particular operation?
>   
You'll need to study the Future spec to get this right. Think of the 
cancel as cancelling the promise of a result. It only returns false if 
the I/O operation has completed or has already been cancelled. It must 
return true otherwise and arrange for any threads blocked on get to 
wakeup and throw CancelledException. Also it must arrange for any 
subsequent calls to isDone to return true.

-Alan.