
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">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. </div><div dir="ltr"><br><blockquote type="cite">On Aug 7, 2023, at 1:25 PM, Attila Kelemen <attila.kelemen85@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">Robert Engels <<a href="mailto:rengels@ix.netcom.com">rengels@ix.netcom.com</a>> ezt írta (időpont: 2023. aug. 7., H, 0:52):<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr">Just like a connect pool to a db - a well designed “resource” has a layer where similar concurrency controls would occur.</div><div dir="ltr"><br></div><div dir="ltr">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)</div><div dir="ltr"><br></div><div dir="ltr">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. </div><div dir="ltr"><br></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div>

</div></blockquote></body></html>