Synchronous executor interface

[Robert Engels]

That’s the point. It is an abstraction that allows flexibility. You have the same concern if your sync blocks on a semaphore indefinitely. 

Your “guarantee” of synchronous in your api is not a guarantee. The constraints are under specified. It would be up to the implementation. Similarly - a synchronous Executor is trivial - and how it works it based on the specific implementation. 

> On Aug 8, 2023, at 10:07 AM, Attila Kelemen <attila.kelemen85 at gmail.com> wrote:
> 
> 
> robert engels <rengels at ix.netcom.com> ezt írta (időpont: 2023. aug. 8., K, 1:52):
>> But why not? Future is pervasive - and then the user can easily switch between synchronous executors and async executors with no user code change - and 0 changes to the JDK.
>> 
> 
> Because Future does not convey the idea that it must be synchronous (in fact, it hints otherwise), and doing something like this is dangerous for async executors, because it is often hard to argue about the context you are called in:
> 
> ```
> // ExecutorService executor
> var result = executor
>   .submit(() -> whatever_action)
>   .get();
> ```
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230808/0877c913/attachment.htm>