Synchronous executor interface

[Attila Kelemen]

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/59d8c7f9/attachment-0001.htm>