On Sun, Sep 25, 2016 at 11:22 PM, David Holmes <davidchol...@aapt.net.au> wrote:
> 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. > Agreed. > > > 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> 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] *On Behalf Of *Viktor Klang > *Sent:* Sunday, September 25, 2016 9:03 PM > *To:* Martin Buchholz <marti...@google.com> > *Cc:* 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! > > > > > > > > On Sun, Sep 25, 2016 at 12:34 PM, Viktor Klang <viktor.kl...@gmail.com> > wrote: > > > > > > On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz <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> 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> > 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 > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > > _______________________________________________ > Concurrency-interest mailing list > concurrency-inter...@cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > -- Cheers, √
