Joe,
That is ignoring the error case. If the cancel fails then it is not complete and it is not cancelled. We added the extra wording back in August 2005. It is interesting to note that Martin’s initial query then only related to the state of the thread, but that it was clear about things only happening if cancel returned true: “My guess is that if cancel(true) returns true, then subsequent cals to isCancelled() and isDone() will return true, *even if the thread executing the task is still running*“ Yet we somehow added the clarification with no regard as to whether cancel returned true or not. That seems wrong. David From: Concurrency-interest [mailto:concurrency-interest-boun...@cs.oswego.edu] On Behalf Of Joe Bowbeer Sent: Monday, September 26, 2016 12:20 AM To: David Holmes <dhol...@ieee.org> Cc: Martin Buchholz <marti...@google.com>; concurrency-interest <concurrency-inter...@cs.oswego.edu>; core-libs-dev <core-libs-dev@openjdk.java.net> Subject: Re: [concurrency-interest] We need to add blocking methods to CompletionStage! This statement regarding what happens after cancel is called is correct: "After this method returns, subsequent calls to isDone() will always return true. Subsequent calls to isCancelled() will always return true if this method returned true." After cancel returns, the future is completed, hence isDone. If cancel returns true, i.e. it was cancelled, then isCancelled returns true. But, for example if the future is already completed when cancel is called, then cancel will return false and isCancelled will return false. On Sep 25, 2016 6:49 AM, "David Holmes" <davidchol...@aapt.net.au <mailto:davidchol...@aapt.net.au> > wrote: I think that was meant to read “After this method returns _true_, subsequent calls …” David From: Concurrency-interest [mailto:concurrency-interest-boun...@cs.oswego.edu <mailto:concurrency-interest-boun...@cs.oswego.edu> ] On Behalf Of Viktor Klang Sent: Sunday, September 25, 2016 9:03 PM To: Martin Buchholz <marti...@google.com <mailto:marti...@google.com> > Cc: concurrency-interest <concurrency-inter...@cs.oswego.edu <mailto:concurrency-inter...@cs.oswego.edu> >; core-libs-dev <core-libs-dev@openjdk.java.net <mailto:core-libs-dev@openjdk.java.net> > Subject: Re: [concurrency-interest] We need to add blocking methods to CompletionStage! On Sun, Sep 25, 2016 at 12:34 PM, Viktor Klang <viktor.kl...@gmail.com <mailto:viktor.kl...@gmail.com> > wrote: On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz <marti...@google.com <mailto:marti...@google.com> > wrote: No one is suggesting we add cancel to CompletionStage - I agree that would break users, by making an immutable interface mutable. +10000 This also means that CompletionStage cannot extend Future. +10000 I also would not want to have a toFuture method that would return a j.u.c.Future, because of misfit Future.cancel. Would you mind elaborating here? According to the cancel method spec on Future it is completely fine for it to be a no-op which always returns false: "This attempt will fail if the task has already completed, has already been cancelled, or could not be cancelled for some other reason." Source: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Future.html There's an interesting (read: weird) spec clause in cancel: "After this method returns, subsequent calls to isDone() will always return true. Subsequent calls to isCancelled() will always return true if this method returned true." That clause is in contradiction with the previously quoted line. If we are adding cancel, then it will be to make a new interface, such as the suggested CancellableCompletionStage. I also agree that CompletionStage does *not* represent "a running task of sorts", j.u.c. Future specs are still confusing in that way due to FutureTask heritage. +10000 On Thu, Sep 22, 2016 at 7:51 PM, James Roper <ja...@lightbend.com <mailto:ja...@lightbend.com> > wrote: For example, we often cache futures and return them from a libraries API, if a client could cancel a future, that would break everything else that received that future. On Fri, Sep 23, 2016 at 2:24 PM, Viktor Klang <viktor.kl...@gmail.com <mailto:viktor.kl...@gmail.com> > wrote: PPS: A misunderstanding is that CompletionStage represents a running task of sorts, one that can be cancelled etc. This is not the case. -- Cheers, √ -- Cheers, √ _______________________________________________ Concurrency-interest mailing list concurrency-inter...@cs.oswego.edu <mailto:concurrency-inter...@cs.oswego.edu> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
