hg: nio/nio/jdk: First installation of potential updates for M4
libman at terabit.com.au
Sat May 16 00:01:58 PDT 2009
> 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
"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
a) transitional states RUNNING - (may be some other sub-states like
b) final state DONE - with mutually exclusive sub-states (CANCELLED,
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
can be described by expression:
boolean rc = state.compareAndSet(one of RUNNING substates, one of DONE
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)
2) for the operation for with CompletionHandler invoke completion handle.
At the moment of wakeup 1) or invocation 2) the state is final and
so we know what to do: return result, throw an exception or which callback
Believe me, those rules are deduced from specification and not from looking
at any source code.
I read again about cancellation on
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
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:
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
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 ?
More information about the nio-dev