[External] : Re: A new build and a new structured concurrency API
Alex Otenko
oleksandr.otenko at gmail.com
Thu Nov 18 10:02:40 UTC 2021
I see why break may be an analogue, but don't see why it is the right one.
Right now the tasks finish in one of four ways:
Success with a value
Failure with Exception
Someone aborted, a subclass of Failure
Shutdown
And it is ok to use onComplete for three cases, but not the last? So now
really all handling is spread across two sites, predictably requiring more
code and more complexity in interactions with the other three termination
conditions.
Alex
On Wed, 17 Nov 2021, 23:28 Ron Pressler, <ron.pressler at oracle.com> wrote:
>
>
> > On 17 Nov 2021, at 21:48, Alex Otenko <oleksandr.otenko at gmail.com>
> wrote:
> >
> > Thanks for the great update.
> >
> > I am trying to comprehend the implications of fork with onComplete.
> >
> > The docs say onComplete may not be invoked at all. What is being saved
> here, compared to cancel() that guarantees onComplete will be invoked.
> >
> > The other thing that seems odd is that onComplete is entirely
> side-effecting: it has no communication with the task that got completed
> (the task can't delegate responsibility for anything), and no communication
> with the consumer of Future (onComplete can't delegate responsibility for
> anything). Like, I borrow a connection - who's going to return it and how?
> I'd expect someone to have one last glance at the context of the Callable
> to clean up.
> >
>
> Completion handlers allows you to factor out policies for the common and
> simple cases where you need to collect results or shutdown the executor
> session based on the task’s success or failure. A call to shutdown
> indicates that the computation is done — either successfully or
> unsuccessfully — and so there’s no point in processing further results. In
> more complicated — and, we believe, much rarer — cases, like the connection
> example in the javadoc, the completion handler is, indeed, insufficient,
> and you’d want to do cleanup processing inside the task and possibly call
> shutdown directly (shutdown is the concurrent analogue to a break statement
> in sequential loop).
>
> — Ron
More information about the loom-dev
mailing list