Synchronous executor interface

[Robert Engels]

You wouldn’t design it that way. The database driver would (or database) would control the concurrency - and it would be configured externally. Why would attempt to do this at the app level - the database is an external shared resource. 

> On Aug 6, 2023, at 3:07 PM, Attila Kelemen <attila.kelemen85 at gmail.com> wrote:
> 
> 
> Robert Engels <rengels at ix.netcom.com> ezt írta (időpont: 2023. aug. 6., V, 21:26):
>> I think what you are asking is so specialized you should just write your own framework. Everyone else with either use a thread or execute on a different. 
> 
> Framework would be quite a big word for a single interface :) That is, implementations are completely optional, maybe with the exception of the trivial implementation to have as a sensible default.
> 
> Also, I would expect that I'm not the only one who uses executors to restrict the number of concurrent usage of a resource (e.g., to not put a DB under useless pressure). If so, currently Loom is a bit of a trap, because it tells developers to just call everything synchronously, but if they do, they will be forced to notice that they were lied to, because calls that are blocking usually use some resources that you should not bombard. So they will need some abstraction of a synchronous executor. Otherwise they will have to use executors, and discard the benefit of Loom. Of course, it is trivial to create such an abstraction, but the JDK providing it has the benefit of creating a standard to communicate this property across libraries.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230806/1b942ffe/attachment-0001.htm>