We need to add blocking methods to CompletionStage!

[Martin Buchholz]

On Fri, Sep 23, 2016 at 2:24 PM, Viktor Klang <viktor.klang at gmail.com>
wrote:

>
> PS. As a sidenote, Martin, and in all friendliness, "actor purist API"?
> C'mon, I know you're better than that! CompletionStage's design has nothing
> to do with Actors and if Single Responsibility Principle is considered
> purism then I'm not sure why we don't have a single interface with all
> methods in it.
> Let's try to keep things friendly.
>

Let's be best friends!

The programming profession is still learning how to write concurrent
programs, fumbling in the dark, and that's particularly true for myself!
There are competing approaches and we don't know which will prove
successful.

PPPS: Adding blocking methods without mandatory timeouts has in practice
> proven to be a recipe for disaster.
>

Hmmmm... By design, Unix processes that create subprocesses should dedicate
a thread for each subprocess, that waits indefinitely in waitpid.  Linux
kernel folks deliberately decided this was fine.  In the Real World, one
needs to interface with Other Peoples' APIs.

Software that rarely blocks is a great idea.  Especially the folks who
write network server infrastructure increasingly agree.  But it is truly a
difficult paradigm shift; we will get there slowly.

---

Say you are implementing some existing function with a traditional
synchronous API.  Your implementation is multi-threaded, but that's an
implementation detail.  Before you return to the caller, you must wait for
the various parts of your computation to complete (the "join" part of
fork/join).  It seems reasonable to wait forever.  If some part of your
computation is interacting with an unreliable external resource, then it
makes sense for that particular "wait" (which need not occupy a thread) to
have a timeout.  Test methods, main methods and unix process reapers are
all examples where it's reasonable to block forever.


> PPPPS: "I think it's unreasonable to not provide this for users
> (especially when we can do so more efficiently)." <- If efficiency is
> desired then blocking is definitely not the right solution.
>

What about efficiently providing isComplete?

The result may already be available without actually blocking.  It may even
be known to be available immediately.  One would like to get the value
without additional allocation.