[StructuredTaskScope] Poor man's "back pressure" ?

[Holo The Sage Wolf]

> 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-, <
benoit.lefevre at decathlon.com> 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 <attila.kelemen85 at gmail.com>
> 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 <alan.bateman at oracle.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20251223/3082633b/attachment.htm>