Resource Constrained Thread Per Task Executor

robert engels rengels at
Fri May 31 22:09:36 UTC 2024

Btw, I posted a concurrency restricted VirtualThreadExecutorService in another thread for those that may be interested:

> On May 13, 2024, at 5:36 PM, Colin Redmond <Colin.Redmond at> wrote:
> You know what, you are right. I double checked the interface that Spring Integration was expecting and it only needs a Executor, not an ExecutorService. I got mixed up and started down the wrong rabbit hole! So you are correct, I don't need to manage the lifecycle and it is a much simpler problem with maybe 10 lines of code.
> From: robert engels <rengels at>
> Sent: May 13, 2024 3:07 PM
> To: Colin Redmond <Colin.Redmond at>
> Cc: Attila Kelemen <attila.kelemen85 at>; masoud parvari <masoud.parvari at>; loom-dev at <loom-dev at>
> Subject: Re: Resource Constrained Thread Per Task Executor
> If you use an Executor the entire code should be less than 10 lines -  then you don’t need to manage the lifecycle, etc. - all it is is a semaphore and the spawning of a new virtual thread when then the semaphore is granted.
> If you need to return Futures for cancellation / results it is a bit more complicated but not much.
>> On May 13, 2024, at 4:34 PM, Colin Redmond <Colin.Redmond at <mailto:Colin.Redmond at>> wrote:
>> Thanks for the idea, the AbstractExecutorService​ would be a great starting place, and that means I need to implement all the shutdown logic. Which is manageable, but tricky. I guess the moral of the story is there is no easy way out of the box to implement constrained resources with new thread per task executors. I will have to write some code and reimplement some things to get what I want.
>> But maybe someone can answer me the question: is it safe to keep a virtual thread for an extended period of time? Maybe I can live with my ThreadPoolExecutor solution if it is safe. For my use case it works, but it isn't ideal.
>> Thanks all for the feedback!
>> From: Attila Kelemen <attila.kelemen85 at <mailto:attila.kelemen85 at>>
>> Sent: May 13, 2024 2:22 PM
>> To: Colin Redmond <Colin.Redmond at <mailto:Colin.Redmond at>>
>> Cc: masoud parvari <masoud.parvari at <mailto:masoud.parvari at>>; Robert Engels <rengels at <mailto:rengels at>>; loom-dev at <mailto:loom-dev at> <loom-dev at <mailto:loom-dev at>>
>> Subject: Re: Resource Constrained Thread Per Task Executor
>> You can't really acquire everything at once, because you might get so many tasks that you could never fulfil such a request. That said, `invokeAll` can simply be done by submitting all tasks one after another. Implementing `invokeAny` well might be trickier, but I have never seen anyone ever using it, so I wouldn't worry too much about it. But you can check `AbstractExecutorService` for both. In fact, you can actually use it as a base class to provide implementation for the invoke many methods.
>> Colin Redmond <Colin.Redmond at <mailto:Colin.Redmond at>> ezt írta (időpont: 2024. máj. 13., H, 23:05):
>> I may be overthink this. I was hoping for an easy way to extend the ThreadPerTaskExecutor like the ThreadPoolExecutior is extensible. But I Agree in this case that it should wrap another executor as getting threading correct is hard! For the Executor Service, Execute and Submit would he easy to manage, as it is a single task so easy to get a acquire a single resource from a semaphore. But I will need to be more careful around invokeAll and invokeAny, as I may need to acquire more permits than are available or one invoke all may block another invoke from executing in parallel. So maybe I can submit them one at time, or just go ahead and get the number of permits at once.
>> It is good to know that i dont need to use any jdk.internal classes. I saw both ThreadPerTaskExecutor  and ThreadPoolExecutor using ThreadContainer and i wasn't sure if it was some special class to manage threads. I can implement something without this.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the loom-dev mailing list