Cancellation test failures

Alan Bateman Alan.Bateman at Sun.COM
Wed Apr 30 15:41:12 PDT 2008


Arkadiy Sutchilin wrote:
> Hi Alan,
>
> I understand that you are extremelly busy now, so I do not expect 
> quick reply.
>
> My AsynchronousServerSocketChannel.accept() test suite should include 
> a couple of tests for IoFuture.cancel(boolean) method - for both 
> "graceful" and "forceful" cancellation.
>
> The problems are the following:
>
> The IoFuture spec says:
>
> (1) "This method otherwise behaves exactly as specified by the Future 
> interface."
>
> The Future spec, in turn, says:
>
> (2) "After this method returns, subsequent calls to isDone() will 
> always return true."
>
> (3) "Subsequent calls to isCancelled()  will always return true if 
> this method returned true."
>
> ----------
>
> The test scenario:
> -- initial state: AsychronousServerSocketChannel is open and bound to 
> a local port;
> -- invoke accept(attacment, handler);
> -- ensure that accept has returned IoFuture in pending state;
> -- invoke IoFuture.cancel(boolean)
> -- analyze returned value and post-conditions.
>
> ----------
>
> A "graceful" cancellation - cancel(false) - constantly returns false.
> isDone() returns false - OOPS - that contradicts (2).
> isCancelled() returns false - OKAY.
> Trying to connect - OKAY, all the channels are open and functional, 
> completion handler has been invoked.
>
> Graceful cancellation is not supported, cancel(false) is ignored and 
> isDone() == false seems reasonable, while contradics (2)
>
> ----------
>
> A "forceful" cancellation - cancel(true) - constantly returns true.
> isDone() returns true - OKAY
> isCancelled() returns false - OOPS - that contradicts (3)
> The channel is closed - that could be expected.
>
> Forceful cancellation actually closes the channel and isCancelled() == 
> false seems reasonable, while contradicts (3)
>
> ----------
>
> IMHO, the implementation's behavior seems reasonable and consistent, 
> while "inherited" Future assertions look inappropriate. That would be 
> great to document at least the following:
>
> Override (2):
> IoFuture.cancel(???) == false && IoFuture.isDone() == false
> combination is permissible and indicates, that cancel(???) had no 
> effect and left the operation in pending stste;
>
> Override (3):
> in case of forceful cancellation
> IoFuture.cancel(true) == true && IoFuture.isCancelled() == false
> combination is permissible and indicates, that cancel(true) has closed 
> the channel.
>
> I have not tested other asynchronous operations yet, so my proposals 
> may appear too narrow and inconsistent with a big picture. Please feel 
> free to ignore these ones and look for more appropriate solution.
Great mail and I'm happy you have caught this. The simplest approach is 
for IoFuture#cancel to specify how isDone and isCancelled should behave 
for the case that cancel(false) is a no-op, and cancel(true) closes the 
channel. That would intentionally violate Future's contract for cancel 
but since we are deviating anyway it may not be too bad. I'll need to 
get input from Doug and Mike (co-conspirators for this area) to get 
opinions. Will get back to you soon.

-Alan.




More information about the nio-dev mailing list