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

[Mike Rettig]

>> StructuredExecutor.open(String
<https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/String.html>
 name, ThreadFactory
<https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/ThreadFactory.html>
 factory)

Does it require a thread per task? Why not create a new interface called
TaskExecutor that could be backed by a virtual thread per task, a platform
thread per task, or a thread pool?

>>Task TaskExecutor.new
<https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/ThreadFactory.html#newThread(java.lang.Runnable)>
Task(Runnable
<https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/Runnable.html>
 r)

Task can be an interface that provides the basic start, join, and interrupt
methods. Since it is a new interface it could add task specific methods
like cancel.


Mike


On Mon, Nov 15, 2021 at 5:20 PM Ron Pressler <ron.pressler at oracle.com>
wrote:

>
>
> > On 15 Nov 2021, at 22:01, Mike Rettig <mike.rettig at gmail.com> wrote:
> >
> >
> > I think the cancellation mechanism needs to be addressed first. The
> "correct" way to handle thread interrupts is already unclear in many cases.
> Requiring it to mean "cancel" when used with structured concurrency is
> going to be difficult for developers.
> >
>
> Cancellation is mentioned in the non-goals section of the JEP precisely
> because we acknowledge there’s a problem
> that will be addressed by *other* work. Interruption is the only
> cancellation mechanism we currently have in the JDK,
> and it is already supported by most blocking APIs. We believe that we’ll
> be able to offer an alternative that could be
> compatible with interruption (and, therefore, not require an API change
> here), but that alternative will be offered
> separately. For the moment, reporting on your experience with this JEP
> would be helpful.
>
> — Ron
>
>