[concurrency-interest] CountedCompleters

Wolfgang Baltes wolfgang.baltes at laposte.net
Sat Apr 21 08:54:22 EDT 2012


Thanks, Doug, for implementing this and providing the update to this 
list. I guess all this will come with JDK 8, and not before!?
Wolfgang.

On 2012-04-21 14:13, Doug Lea wrote:
> 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
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>


More information about the Concurrency-interest mailing list