hg: nio/nio/jdk: First installation of potential updates for M4
Alan.Bateman at Sun.COM
Sat May 16 04:24:46 PDT 2009
Alexander Libman wrote:
> 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?
Yes, as you don't want it to interfere with other I/O operations.
> 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?
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).
> 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().
No, you should simply update its state to cancelled, release any
waiters, and return *true*. Everything falls into place after that. That
is, isDone and isCancelled will return true and any subsequent calls to
get will throw CancellationException.
> 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
> return true".
> This force me to wait in cancel () if operation is not cancellable "for
> some other reason".
I tripped up on this too and had to be rescued by the jsr166 folks.
There really isn't a third option and you have to return true if the I/O
has not completed or has not been cancelled.
> Last question: is Future.get () idempotent method ?
It always returns the same result as the result from the first invocation.
More information about the nio-dev