[concurrency-interest] CountedCompleters

Doug Lea dl at cs.oswego.edu
Sat Apr 21 08:13:08 EDT 2012


The updated version of CountedCompleter now includes:

     /**
      * Performs an action when method {@link #completeExceptionally}
      * is invoked or method {@link #compute} throws an exception, and
      * this task has not otherwise already completed normally. On
      * entry to this method, this task {@link
      * ForkJoinTask#isCompletedAbnormally}.  The return value of this
      * method controls further propagation: If {@code true} and this
      * task has a completer, then this completer is also completed
      * exceptionally.  The default implementation of this method does
      * nothing except return {@code true}.
      *
      * @param ex the exception
      * @param caller the task invoking this method (which may
      * be this task itself).
      * @return true if this exception should be propagated to this
      * tasks completer, if one exists.
      */
     public boolean onExceptionalCompletion(Throwable ex, CountedCompleter caller)


On 04/17/12 08:47, Wolfgang Baltes wrote:
>
>>
>> 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.
>>
> This is what I do now. But there is already a try construct in the main worker
> thread loop, and this adds an extra try block. This requires some extra time to
> execute, which is even more annoying as it will be executed every time the task
> is run.

I don't believe this extra try-block costs anything -- or if so, not
enough to worry about. The generated instructions for compiled code
of versions using variant conventions are a little different, but
not obviously worse than each other.

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

I'm still not sure about whether or how to address this.
Could you send me examples with more context off-list
so I can contemplate alternatives?

-Doug


More information about the Concurrency-interest mailing list