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

[Martin Buchholz]

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.

---

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.

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...