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

Alan Bateman alan.bateman at oracle.com
Wed Dec 24 08:00:22 UTC 2025


On 23/12/2025 21:58, Attila Kelemen wrote:
> Holo's response is probably your best bet for STS. Otherwise, Alan 
> alluded to an implementation like this (disclaimer: I just typed it 
> into an email, did no testing in anyway):
>
> ```
> ThreadFactory limitedFactory(int limit, ThreadFactory wrapped) {
>     var semaphore = new Semaphore(limit);
>     return r -> {
>         var thread = wrapped.newThread(() -> {
>             try {
>                 r.run();
>             } finally {
>                 semaphore.release();
>             }
>         });
>         semaphore.acquireUninterruptibly();
>         return thread;
>     };
> }
> ```
>
> but as I noted previously, this has the problem that no API makes a 
> general promise that a thread will actually be started.

If you move the acquire into the wrapped task then it will be closer to 
some of the sketches in previous discussions here. That would avoid the 
main task blocking in newThread, and goes to your comment about creating 
but not starting threads too.  There may be > limit Threads but at most 
min(limit, #ncores) would execute concurrently. Using acquire rather 
than acquireUninterruptibly, and handling the InterruptedException, 
would make also make it more responsive when the scope is cancelled 
before some of these subtasks run.

Zooming out a bit. With thread pools the maximum number of threads 
limits concurrency. If the maximum number of threads is less than other 
limits (DB connections, max number of network connections, etc.) then it 
removes/hides the need to have to configure limits on these resources. 
With virtual threads, which STS uses by default, then the limit on the 
number threads is effectively removed to allow for higher concurrency. 
To take advantage might mean configuring limits elsewhere which to more 
fine grain limiting of concurrency. Hopefully in time there will be more 
focus put on more finer grain limits rather than going back to limiting 
the number of threads.

-Alan




More information about the loom-dev mailing list