Synchronous executor interface

[Robert Engels]

I think by the time you cover all of the cases in the api - (eg interrupted/other exception) you are going to end up with the Future/Executor interface anyway. 

> On Aug 7, 2023, at 1:25 PM, Attila Kelemen <attila.kelemen85 at gmail.com> wrote:
> 
> 
> Robert Engels <rengels at ix.netcom.com> ezt írta (időpont: 2023. aug. 7., H, 0:52):
>> Just like a connect pool to a db - a well designed “resource” has a layer where similar concurrency controls would occur.
>> 
>> The throttling is not “http requests” it is the requests to a particular resource - so you have a service endpoint and any required throttling occurs there. (Even if the endpoint is in process)
>> 
>> Still this is not typically how this is done. Think if you are rate limited - by credentials - very common with big tech services - you need another layer across processes to control not exceeding the limit. 
>> 
> 
> The problem is that you might want to make the constraint configurable. And of course, you can do it everywhere separately in a custom manner, but why when there is a generic and flexible way to do so? So far this was often effectively done by having the executor configurable which naturally provided a limit. If we want people to move away from async, then that implies moving away from executors as well (when possible of course), but this would make them discard all the other purposes of executors, and I believe the JDK should fill in the gap it created.
> 
> Also, of course this is not how it is typically done now, because without Loom this is practically impossible as you don't want to just keep wasting threads. However, with Loom this would be a flexible and convenient option, and it is not even that risky, since this is basically just a single interface, any implementation can go to external libraries (or even the application itself can create them, since implementations are trivial to create). I don't want to understate the risk to the JDK, since the risk is always a lot higher when it is the JDK, but a synchronous executor is such a simple concept, that my opinion (obviously) is that it is well worth it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230807/15f3b9f8/attachment.htm>