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

[Alexander Libman]

Alan,

> 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.  ...

> 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.

I think it would be clear to state that the given operation will produce
CancellationException and all other outstanding operations mayl fail with
AsynchronousCloseException.
"Will produce" - I use this term to specify the result of completion
regardless of notification method.


May be I did not explain my concerns clear enough. Will try now.

Basically,  the specifation compels any Future implementation to support
following
state groups:

a) transitional states RUNNING  - (may be some other sub-states like
RUNNING_CANCELLABLE
and RUNNING_NOT_CANCELLABLE).
and

b) final state DONE - with  mutually exclusive sub-states (CANCELLED,
FAILED, COMPLETED)

The following rules are applied:

State transitions inside group a) are allowed.
Only one transition from  group a) to any DONE state is allowed.
Once we moved to  DONE  group  no more transitions are  allowed.
Transitions are atomic (implementation can use synchronization locks), but
the algorithm
can be described by expression:
      boolean rc = state.compareAndSet(one of RUNNING substates, one of DONE
substates);

Once transition to DONE group  is made, we must either:
1) for the operation form with Future<>  wakeup all waters of Future.get()
by broadcasting on condition (or any other similar mechanism).
On wakeup we have to return the result value or throw a exception
(CancelledOpeartion or any other ExecutionException)
or
2) for the operation for with CompletionHandler  invoke completion handle.

At the moment of wakeup 1) or  invocation 2)   the state is final and
non-modifiable anymore,
so we know what to do:  return result, throw an exception or which callback
to invoke.

Believe me, those rules are deduced from specification and not from looking
at any source code.


I read again about cancellation on
http://openjdk.java.net/projects/nio/javadoc/java/nio/channels/AsynchronousC
hannel.html

My understanding is that implementation can use close() only if
mayInterruptIfRunning is set to true.
And in such case cancellation can impact on other outstanding operations for
the given channel.

Otherwise (mayInterruptIfRunninng = false) it is prohibited to call close()
inside the implementation
and all other pending operations on this channel should not be affected.
Am I right?

It is also said that  "....then the channel is put into an implementation
specific error state that prevents further attempts to initiate I/O
operations on the channel."
And what about other already pending operations in case of
mayInterruptIfRunninng = false?
Is allowed to force their failure?

What should we do if mayInterruptIfRunninng = false and there is no way to
cancel/fail/complete immediately?
Seems, the only one alternative is to block in cancel().

Reading "...If an implementation of this interface supports a means to
cancel I/O operations",  I assumed
that cancel  implementation  is optional.  Here it was my mistake!

It is not optional, it is mandatory according to:
http://download.java.net/jdk7/docs/api/java/util/concurrent/Future.html

boolean cancel(boolean mayInterruptIfRunning)

Attempts to cancel execution of this task. This attempt will fail :
a)if the task has already completed (OK)
b)has already been cancelled (OK)
c)or could not be cancelled for some other reason  (??)

I would like to use the third option ("for some other reason",i.e. not
cancellable)  and return false.
But "  After this method returns, subsequent calls to isDone() will always
return true".
This force me to wait in cancel () if  operation is not cancellable "for
some other reason".

Sorry, I missed Future description as I got used to traditional POSIX and
Windows semantic for cancellation return codes:
CANCELED , NOTHING_TO_CANCEL, NOT_CANCELLED
The code NOT_CANCELLED means it will be completed later, but cancel call
would not block.

May be blocking in cancel ()  is OK since cancel()  can be called only for
the Future<> forms and the caller should call get()  in any case?
And scalable appliactions will always use CompletionHandler, where cancel()
in not accessible now.

Last question: is Future.get () idempotent method ?

Thank you,
Alex