[concurrency-interest] CountedCompleters

Doug Lea dl at cs.oswego.edu
Tue Apr 17 07:32:00 EDT 2012

Thanks for the suggestions!

On 04/16/12 10:48, Wolfgang Baltes wrote:
> 1: Symmetrically to onCompletion(), provide onExceptionalCompletion(Throwable).
> This allows filtering exception propagation. There are cases where the
> propagation of the exception is desired, and others where a corrective action is
> taken instead, such as a retry.

This is a good idea. One way to do it is to support
   boolean onExceptionalCompletion(Throwable t, CountedCompleter c) {
      return true; // default
that returns false if the exception should not be further propagated
to this task's completer. I had this (without a default) in several
preliminary versions but left it out in attempt to further simplify API.
But given that it can be done with a sensible default, it makes sense
to reinstate it. I'll do this in next commit (which might not be for a
week or so).

> 2: As a further enhancement to 1: enable any Throwable, including checked
> exceptions.

The issue boils down to where we'd like users to place exception
code. In the current scheme, any task doing IO etc can do:
   try {
   } catch(IOException ex) {
      completeExceptionally(ex); // or throw new Error(ex)

... as opposed to placing the call to compute() itself in
a try/catch. My take is that the current scheme is a little
easier and slightly more pleasant to use. Counter-examples
would be welcome though.

> 3: Provide a method to join a task that is not forked and/or not completable,
> while minimizing worker thread blocking.

Whenever you find yourself wanting to do this, there are better
alternatives that entail creating little trigger
objects. See for example CCBoxedLongSort in
I'll add some further examples sometime hopefully soon.


More information about the Concurrency-interest mailing list