[External] : Re: Future.resultNow / exceptionNow

[Eric Kolotyluk]

Agreed, I did mis-parse your sentence.

Agreed, "designing concurrency APIs is hard, and doubly so when new
paradigms are involved"

I was not critiquing so much as using an overly assertive clarification, so
I will try to make the questions clearer.

I am trying the new APIs and paradigms, that is what my loom-lab project is
all about. I am learning more from the code experiments than the
documentation, which is normal because writing documentation is hard.

Cheers, Eric

On Sun, Nov 21, 2021 at 11:06 AM Brian Goetz <brian.goetz at oracle.com> wrote:

>
>
> On 11/21/2021 1:57 PM, Eric Kolotyluk wrote:
>
> Just to clarify...
>
> "(optional) deal with results and errors"
>
> If you want to call Future::resultNow then dealing with errors first is
> not optional, or you are inviting an IllegalStateException.
>
>
> I think you may have mis-parsed my sentence?  "Optional" applies to the
> whole sentence; for many tasks, there is no result, only side-effects, so
> there's no need to deal with results, so no need to call Future::resultNow
> (in fact, likely no need for keeping the futures at all in this case.)
>
> Again, as Ron has pleaded: PLEASE TRY IT, rather than critiquing in a
> vacuum; designing concurrency APIs is hard, and doubly so when new
> paradigms are involved.  If you are having trouble figuring out how to try
> it, ask questions!
>
> Cheers,
> -Brian
>
>
>
>
> On Sun, Nov 21, 2021 at 10:49 AM Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
>>
>> > When you throw an exception*because of another exception*  it is far
>> better
>> > to add it as the cause, than to throw one with no cause. If you don't
>> > include the cause, you are hiding the root issue that needs to be
>> solved.
>> > Yes, we may be using the API improperly, but are trying to teach people
>> to
>> > use the API properly, or are you just trying to make it annoying if they
>> > _don't_  use it properly?
>>
>> The API is designed to follow a simple pattern:
>>
>>      create an SE, always in a TWR header
>>      fork some tasks
>>      wait for them all to finish (there's a method for this)
>>      (optional) deal with results and errors, if needed, in accordance
>> with selected error-handling policy
>>      implicitly close by falling out of TWR
>>
>> In most cases, this will fit on half a page or less of code.
>>
>> We don't strictly need resultNow, but if we didn't add it, people would
>> complain that gathering results with Future is annoying (and they'd be
>> right) because Future forces you to deal with all the possible states,
>> often by catching exceptions, even though, if you follow the above
>> simple pattern, you *already* know what state the Future is in.  [1]
>>
>> It's natural to ask "but how can I be sure", but the API is designed to
>> be simple enough that it is *hard to get wrong*, once you learn the
>> idiom once.  Three phases: fork tasks, wait for tasks, optionally handle
>> results.  Given that, it will surely be annoying if there is any
>> gratuitous unpacking friction; it will feel like needing both belt and
>> suspenders.  Wrapping the result in Optional is less annoying than
>> dealing with the exceptions of Future, but its still annoying, and,
>> still unnecessary.  (And, if we did wrap it in an Optional, the same
>> complaint about "why is the optional empty, you should wrap the
>> exception" would come up.  At which point we've reinvented the existing
>> Future::get API.)
>>
>> As Ron has suggested several times, rather than redesigning the API in a
>> vacuum, its probably best to *go try it* and report back your
>> experience.  Much of what comes out of Project Loom involves unlearning
>> things we had to do before because of accidental constraints like
>> "threads are expensive to create."  The idioms we have internalized are
>> conditioned by the reality we used to be stuck with, but no longer are.
>> The natural idioms we will equilibrate to after such a big change in
>> cost model may be slightly unintuitive at first, but give them a chance.
>>
>>
>>
>>
>>
>> [1] If your policy is complicated, it may require some bookkeeping to
>> sort the succeeded from failed tasks, but that's what the handler object
>> is for, and it's easy to write handlers even for complex policies like
>> "abort if two red tasks succeed before three blue tasks fail".
>>
>>
>>
>