Hello Thanks Attila & Alan for your feedback, and sorry for this late reply of mine.
Weeks before Christmas are pretty busy at work :p @Attila : I quickly thought about something like what you advise. But even if I know that in such a case I should make some kind of "atomic assertion or +1" after each .fork() calls, I don't have a clue upon which event I have room to make the corresponding "atomic assertion & -1" with the new API. If it's still possible with it, I have most probably missed something. I remember that in its previous version, there were some kind of callbacks methods whose implementations could be overloaded. But now the API is much more composition oriented, where do you advise to code this ? @Alan : Do you have the references of those discussions by any changes ? As is, it's not straightforward for me to understand how the ThreadFactory can keep track or be warned whenever a thread it created complete. Le lun. 15 déc. 2025 à 21:50, Attila Kelemen <[email protected]> a écrit : > Yeah, I was on those threads. Though I much dislike the idea doing this > with a `ThreadFactory`, because then you would have to do an `acquire` > before returning a thread, and generally no API makes the promise that a > thread created by the factory will be started (though would be unusual, but > still I prefer to code for the contract). If you want to abstract it, then > it is way better to hide this behind an `Executor` (or `ExecutorService`) > where you can implement this properly (if we restrain ourselves to JDK > interfaces). > > Alan Bateman <[email protected]> ezt írta (időpont: 2025. dec. 15., > H, 21:32): > >> >> >> On 15/12/2025 19:29, Attila Kelemen wrote: >> > If I'm understanding your problem correctly, then you can just use >> > semaphores to limit the number of concurrent actions. >> > >> There are a few other threads to the same topic in the archives. Using a >> ThreadFactory that limits concurrency is one of the options that others >> were trying out. >> >> -Alan >> > -- Benoit Lefèvre
