Resource Constrained Thread Per Task Executor

[Colin Redmond]

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 ix.netcom.com>
Sent: May 13, 2024 3:07 PM
To: Colin Redmond <Colin.Redmond at outlook.com>
Cc: Attila Kelemen <attila.kelemen85 at gmail.com>; masoud parvari <masoud.parvari at gmail.com>; loom-dev at openjdk.org <loom-dev at openjdk.org>
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 outlook.com<mailto:Colin.Redmond at outlook.com>> 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 gmail.com<mailto:attila.kelemen85 at gmail.com>>
Sent: May 13, 2024 2:22 PM
To: Colin Redmond <Colin.Redmond at outlook.com<mailto:Colin.Redmond at outlook.com>>
Cc: masoud parvari <masoud.parvari at gmail.com<mailto:masoud.parvari at gmail.com>>; Robert Engels <rengels at ix.netcom.com<mailto:rengels at ix.netcom.com>>; loom-dev at openjdk.org<mailto:loom-dev at openjdk.org> <loom-dev at openjdk.org<mailto:loom-dev at openjdk.org>>
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 outlook.com<mailto:Colin.Redmond at outlook.com>> 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: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240513/8ba9cad5/attachment-0001.htm>