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

Viktor Klang viktor.klang at gmail.com
Sun Sep 25 07:03:21 EDT 2016


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,
√
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160925/1ec2bb32/attachment-0001.html>


More information about the Concurrency-interest mailing list