Loom on Scala

[Eric Kolotyluk]

@Alan Bateman <Alan.Bateman at oracle.com>

I noticed that StructuredExecutor has a shutdown() while
newThreadPerTaskExectutor() has both shutdown() and shutdownNow()...

Also, shutdown() on StructuredExecutor is very different...* it is much
more useful.*

The documentation for shutdown()
<https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredExecutor.html#shutdown()>
is not clear to me in that, if shutdown() prepares for join(), in that
join() will then return immediately without waiting, do we still need to
call join() before close()? For example

try {
    structuredExecutor.joinUntil(Instant.now().plusSeconds(10));
}
catch (TimeoutException e) {
    structuredExecutor.shutdown();
    structuredExecutor.join();
}

Why do I still need to call join() a second time?

As an aside, it is concerning me that StructuredExecutor is so very
different than all the other Executors... and that it disrupts my sense of
intuition. StructuredExecutor is clearly better, but it's also disruptive.

Rather than the above try/catch, I would rather write something like

structuredExecutor
    .joinUntil(Instant.now().plusSeconds(10), () ->
structuredExecutor.shutdown() );

Cheers, Eric



On Sun, Nov 28, 2021 at 1:15 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 28/11/2021 01:19, Paul Bjorkstrand wrote:
> > :
> > I could see an additional parameter flag for StructuredExecutor.open()
> > which changes the shutdown implementation from the default "interrupt" to
> > "wait" aka join.
> I suspect you mean "close" rather than "shutdown" here. Having shutdown
> wait would be very deadlock prone (a task would be waiting on itself
> and/or several tasks calling shutdown would deadlock waiting on each
> other).
>
> We've avoided having a configurable parameter to change the close
> behavior. The behavior in the current prototype (where close is
> specified to shutdown) is more useful for cases where there is an
> exception in the block and you fall into the close. It avoids having
> close waiting indefinitely for tasks that you are no longer interested in.
>
> -Alan
>