Synchronous executor interface

[Robert Engels]

Why not use the existing executor services that are not based on virtual threads?

> On Aug 6, 2023, at 8:11 AM, Attila Kelemen <attila.kelemen85 at gmail.com> wrote:
> 
> 
> Hi,
> 
> Loom wants to do away with most of the asynchronous code, but in many cases, the asynchronous invocation was abstracted behind an Executor(Service). However, often executors have a multiple purpose: Most notably, you want to limit concurrency. Since many library code do not actually want to bother deciding how to limit the execution (or what context the tasks should run in), they offer the client code to pass the executor implementation.
> 
> Now that Loom is pushing us toward synchronous code, we are actually left without an executor abstraction, which I believe should be provided by the JDK rather than every library creating its own. So, I propose a new interface (and maybe a few obvious implementations) to be added to JDK. For example, the new executor interface could look like this:
> 
> ```
> interface SynchronousExecutor {
>   <T> T execute(Supplier<? extends T> action);
>   
>   default <T> T execute(Runnable action) {
>     return execute(() -> { action.run(); return null; });
>   }
> }
> ```
> 
> Of course, in this case a new checked exception aware variant of Supplier / Runnable would also be nice to lessen the problem with checked exceptions. (on side note: it is also quite regrettable that it can't be a functional interface ...)
> 
> Also, 4 commonly useful implementations could be:
> 
> - Just immeditaly call the the passed action.
> - Limit concurrency using sempahore.
> - Set scoped values for the provided action.
> - Combine multiple executors into one.
> 
> Attila
>