[concurrency-interest] We need to add blocking methods to CompletionStage!

Viktor Klang viktor.klang at gmail.com
Mon Sep 26 10:30:21 EDT 2016


On Sun, Sep 25, 2016 at 11:22 PM, David Holmes <davidcholmes at 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-
> bounces at cs.oswego.edu] *On Behalf Of *Joe Bowbeer
> *Sent:* Monday, September 26, 2016 12:20 AM
> *To:* David Holmes <dholmes at ieee.org>
> *Cc:* Martin Buchholz <martinrb at google.com>; concurrency-interest <
> concurrency-interest at cs.oswego.edu>; core-libs-dev <
> core-libs-dev at 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" <davidcholmes at 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-
> bounces at cs.oswego.edu] *On Behalf Of *Viktor Klang
> *Sent:* Sunday, September 25, 2016 9:03 PM
> *To:* Martin Buchholz <martinrb at google.com>
> *Cc:* concurrency-interest <concurrency-interest at cs.oswego.edu>;
> core-libs-dev <core-libs-dev at 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.klang at gmail.com>
> wrote:
>
>
>
>
>
> On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz <martinrb at 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 <james at 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.klang at 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-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


-- 
Cheers,
√
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160926/0a8dbcc8/attachment-0001.html>


More information about the Concurrency-interest mailing list