> 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.
All of the user definable behaviour has moved into the Joiner class, when opening a sts you can pass a joiner to it. Joiner has a "onFork" method that invokes whenever you call "scope.fork", a "onComplete" method that invokes whenever a task completes (successfully or unsuccessfully) and "complete" method that invokes from the "scope.join" method (it is invoked *after* all the tasks are supposedly ended) What you want is e.g. a semaphore acquisition in your "onFork" override and a release in your "onComplete". On Tue, 23 Dec 2025, 21:15 Benoit LEFEVRE -CAMPUS-, < [email protected]> wrote: > 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 >
