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

[Joe Bowbeer]

Cancellation: David, I can see your point. Future.cancel(true) was
discussed 8/27/05 and the extra text was added to make it clearer that the
state of Future after cancel is called is separate from the state of any
associated thread or task.

However, I think the added text corresponded too closely to the only
implementation of Future.cancel that existed at the time. Elsewhere the
spec tries to permit Future.cancel to fail for some reason other than
because the Future had already completed:

  "This attempt will fail if the task [...] could not be cancelled for some
other reason."

  "returns false if the task could not be cancelled, typically because it
has already completed normally"

Without the added text, my interpretation would be that if cancel returns
false and then isDone returns false, then cancel failed for some other
reason.

On Sun, Sep 25, 2016 at 5:39 PM, Martin Buchholz 
wrote:

>
>
> On Sun, Sep 25, 2016 at 2:22 PM, David Holmes 
> wrote:
>
>>
>> Yet we somehow added the clarification with no regard as to whether
>> cancel returned true or not. That seems wrong.
>>
>
> Yikes!  I had always assumed that cancel was not permitted to leave the
> Future incomplete, perhaps influenced by the wording,
>
> """After this method returns, subsequent calls to {@link #isDone} will
> always return {@code true}."""
>
> It's much more in the spirit of Java to throw an exception if the future
> cannot be completed.  It's never come up, I think.
>

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

[Joe Bowbeer]

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"  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 
> *Cc:* concurrency-interest ;
> core-libs-dev 
> *Subject:* Re: [concurrency-interest] We need to add blocking methods to
> CompletionStage!
>
>
>
>
>
>
>
> On Sun, Sep 25, 2016 at 12:34 PM, Viktor Klang 
> wrote:
>
>
>
>
>
> On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz 
> wrote:
>
> No one is suggesting we add cancel to CompletionStage - I agree that would
> break users, by making an immutable interface mutable.
>
>
>
> +1
>
>
>
> This also means that CompletionStage cannot extend Future.
>
>
>
> +1
>
>
>
> 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.
>
>
>
> +1
>
>
>
>
>
> On Thu, Sep 22, 2016 at 7:51 PM, James Roper  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 
> 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
>
>