> On 25 Sep 2016, at 22:49, Martin Buchholz <marti...@google.com> wrote: > ...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.
More than that, cancelling the wait does not cancel the computation it was waiting for. You need to time out / cancel the wait at the junctions where you have the power to arbitrate fair use of resource locked up in the caller, by the caller. Alex
