[External] : Re: A new build and a new structured concurrency API

[Alex Otenko]

No problems so far, exploring the mechanism to understand the edge cases to
be aware of, and what would be considered misuse of the API.

This particular clause caught my eye because I have had trouble with
complexity explosion with similar absence of notifications on cancellations
in other APIs, so needed to know what makes it OK here.

Alex

On Fri, 19 Nov 2021, 13:54 Ron Pressler, <ron.pressler at oracle.com> wrote:

> Yes, you can certainly call shutdown manually rather than use the
> completion handler. It will not interrupt its own thread. What happens to
> the future is more subtle, but advanced uses that prefer to call shutdown
> manually rather than in the completion handler won’t be interested in the
> future either.
>
> Regardless, in most situations you should just use the handlers.
>
> Is there a particular problem you’ve run into or are you just asking out
> of curiosity to understand the finer points of the mechanism?
>
> — Ron
>
> On 19 Nov 2021, at 13:12, Alex Otenko <oleksandr.otenko at gmail.com> wrote:
>
> Thanks. Can this be taken literally to mean that a task could shutdown()
> in finally to achieve exactly the same effect, and that won't cancel its
> own Future? (I.e. that if called from inside a task, there is a notion of
> "me", and "cancel all except me" is doable)
>
> Alex
>
> On Fri, 19 Nov 2021, 09:30 Ron Pressler, <ron.pressler at oracle.com> wrote:
>
>> You *can* use a finally clause instead of onComplete. It’s even more
>> general. The purpose of the completion handler parameter is to perform the
>> role you say in a way that’s nicely factored out into a “policy object.”
>> It’s a convenience mechanism, not an essential one.
>>
>> — Ron
>>
>> > On 19 Nov 2021, at 09:00, Alex Otenko <oleksandr.otenko at gmail.com>
>> wrote:
>> >
>> > I think I understand what problem onComplete is solving.
>> >
>> > Basically, everything you want can be done in finally clause of the
>> task,
>> > except cancel all - because that's going to kill the task that calls it.
>> > "Cancel all except me" is hard to implement. So you want something like
>> a
>> > finally, but which gets invoked after the task's Future has settled.
>> >
>> > Yes, if you limit the functionality of onComplete to conditionally
>> cancel
>> > all, then there is no need to invoke it after having cancelled all once
>> -
>> > after all, can't un-cancel, and we limit its purpose to just
>> cancellation
>> > of all, no other aggregation, clean up or introspection of the finished
>> > tasks.
>> >
>> > Alex
>>
>>
>