Synchronous executor interface

[Robert Engels]

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. 

What you propose has very limited utility and for those cases a simple resource access layer is all that is needed. 

> On Aug 6, 2023, at 5:21 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:05):
>> That is nonsensical.  It would mean you would have to pass the supplier to multi threads of execution or you would only have a single execution possible. 
>> 
> I'm not sure where your confusion is coming from. This limits the number of concurrent execution of all the actions passed to it. Of course, you will have to use multiple threads. A single thread does not need to have such a constraint.
> 
>  
>> So the interface does nothing in the case. Use a semaphore if you need to limit concurrency - call the supplier directly if you don’t. 
>> 
>> You added a layer that doesn’t do anything but is obscure the code/intent. 
>>> 
> I think you misunderstand the point. The implementation might not know what kind of constraints you want to put on it. In fact, it is possible that you want to put multiple things under the same constraint. For example, you might want to limit the number of concurrent http calls in your application, and there could very well be independent things making such calls. You don't want to pass around naked semaphores.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230806/1ead45e2/attachment.htm>