[concurrency-interest] We need to add blocking methods to CompletionStage!
viktor.klang at gmail.com
Mon Sep 26 14:29:48 UTC 2016
On Sun, Sep 25, 2016 at 10:01 PM, Martin Buchholz <martinrb at google.com>
> On Sun, Sep 25, 2016 at 7:34 AM, Viktor Klang <viktor.klang at gmail.com>
>> 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
> 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
> 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>
>> 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...
More information about the core-libs-dev