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

[Mike Rettig]

The full interface I would like to see would look more like this:

interface TaskExecutor<T>{
    Task newVoidTask(T t);
    //TODO add tasks that return values...
}

This allows developers to define their own domain specific tasks and decide
how the tasks execute asynchronously. The runtime can coordinate the tasks
and provide visibility to the tooling. Type safety can be enforced and
domain specific methods can be added for complex task coordination.

Providing a type safe, pluggable api would open up a whole new world of
possibilities. An api based on Runnable, Callback, and the thread api is a
great default implementation, but is too limiting for complex scenarios.

Mike

On Mon, Nov 15, 2021 at 6:33 PM Mike Rettig <mike.rettig at gmail.com> wrote:

>
> >> 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
>>
>>