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

[Viktor Klang]

On Sun, Sep 25, 2016 at 10:01 PM, Martin Buchholz <martinrb at google.com>
wrote:

>
>
> On Sun, Sep 25, 2016 at 7:34 AM, Viktor Klang <viktor.klang at gmail.com>
> wrote:
>
>> If that truely is the case then the only way of implementing a readonly
>> Future is by throwing an exception from cancel...
>>
> We the maintainers of j.u.c.Future have always thought that canceling a
> Future will surely leave it completed.  Of course, implementers of any Java
> interface can choose to throw UOE for any method, but this is not intended
> for Future.cancel.  An interface without cancel probably should not be
> extending Future.
>

This seems to have been "addressed" further down this thread.


>
> ---
>
> Here's another way to think of the range of functionality between current
> CompletionStage and current CompletableFuture:
>
> - Add Polling methods from scala Future such as isCompleted
> <http://www.scala-lang.org/api/2.12.0-RC1/scala/concurrent/Future.html#isCompleted:Boolean>
> These are also discouraged, but less so than Await methods
> """Note: using this method yields nondeterministic dataflow programs."""
> Will adding these to CompletionStage be less controversial?
>
> - Add Await blocking methods (that in scala cannot be called directly,
> using the CanAwait mechanism)
>
> - Add cancellation
>
> - Add other methods to complete the future ("Promise")
>
> - Add the full CompletableFuture API, including the obtrude methods
>

> Cancellation is interesting, because it's a mutating method, and so cannot
> be used with a future shared with other users, but it also seems very
> reasonable as a "client" operation.  One can think of obtaining a
> non-shared future as a subscription to a one-time event, and that
> subscription takes up resources in the form of an object.  If the client is
> no longer interested in the event, then cancellation of the future can free
> up resources.  I'm still thinking of what Process.onExit
> <http://download.java.net/java/jdk9/docs/api/java/lang/Process.html#onExit-->
> should return.  There's a tension between the various roles that
> CompletableFuture serves - as a container to write a value, as a possibly
> cancellable subscription to that value, and as a way to chain async
> computations together.
>

I'd rather suggest creating a 2.0 of FutureTask (i.e. represent the Task
part separately from the Future part)
Have something represents something being executed somewhere else, that can
support cancellation but also expose a read-only facet of itself.

I think you're right in that something is missing which would lie somewhere
in between CompletionStage and CompletableFuture.
What methods would you propose to add to such an interface and why?


>
> On Wed, Sep 21, 2016 at 2:25 PM, Benjamin Manes <ben.manes at gmail.com>
> wrote:
>
>> I've gradually come to terms using CF as part of an API and haven't
>> experienced a downside yet.
>>
>
> Hmmmm.... I seem to be moving in that direction as well...
>



-- 
Cheers,
√