[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 {
     io();
   } catch(IOException ex) {
      completeExceptionally(ex); // or throw new Error(ex)
      return;
   }

... 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
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/loops/
I'll add some further examples sometime hopefully soon.


-Doug




More information about the Concurrency-interest mailing list