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

[Viktor Klang]

If that truely is the case then the only way of implementing a readonly
Future is by throwing an exception from cancel...

-- 
Cheers,
√

On Sep 25, 2016 4:20 PM, "Joe Bowbeer" <joe.bowbeer at gmail.com> wrote:

> 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-b
>> ounces 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/concurre
>> nt/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
>>
>>