Synchronous executor interface

[Attila Kelemen]

Robert Engels <rengels at ix.netcom.com> ezt írta (időpont: 2023. aug. 8., K,
18:12):

> That’s the point. It is an abstraction that allows flexibility. You have
> the same concern if your sync blocks on a semaphore indefinitely.
>
>
The point is to move away from async, and an API that explicitly promotes
async is misleading at best when the code you are writing by definition is
synchronous. That is, it conveys to your client code (by type) that you
somehow wants to run things asynchronously.

Also, it is not exactly the same:

1. It does not conflate concepts (async + concurrency restriction). So, it
is a lot less likely that somebody just submits a task to it, ending up
calling back to the executor.
2. More importantly: It is trivial to improve the naive semaphore based
implementation to be reentrant depending on what is the actual need for the
constraint. The same behaviour would require a custom implementation of
ExecutorService (and would still be problematic, if multiple thread pools
are being used, instead of writing plain synchronous code), and an
ExecutorService is way more difficult to implement.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230808/7d5b26ff/attachment.htm>