Jetty and Loom

[Ron Pressler]

On 4 January 2021 at 17:55:58, Greg Wilkins (gregw at webtide.com (mailto:gregw at webtide.com)) wrote:

> I'm just saying that there are other reasons for using them
> other than just because kernel threads are slow to start. In the right
> circumstance, a thread pool (or an executor that limits concurrent
> executions) is a good abstraction. My stress on them is in reaction to
> the "forget about thread pools" meme, which I think would be better as a
> little less shiny projectile sounding.


A thread pool is not “an executor that limits concurrency.” It is a pool of
threads, which, as a side-effect of threads representing concurrency,
also happens to limit concurrency. The purpose of any kind of pool is to
avoid the cost of creating and disposing of objects. If the objects are
created and disposed-of cheaply, as is the case with virtual threads,
they should not be pooled. Platform threads, however, because they are
expensive, should be.

If you wish to limit the concurrency of operations carried out on virtual
threads, you should use constructs aimed at limiting concurrency, such
as semaphores. They offer benefits over thread pools — e.g. different 
operations on the same set of threads can have different concurrency
limits — and they don’t suffer from the significant downsides of thread
pools, such as making interruption very complicated, and leaking context
from one task to another.

There might be some reasonable use-cases for an executor that limits 
concurrency without pooling the threads, though, and it should be easy
to implement, but I’m not sure it should be included in the core libraries.

I cannot think of a good use for pooling virtual threads, and it seems to
me that any such use would be an anti-pattern with big downsides and no
upsides, but if anyone can think of a good reason to pool cheap objects,
please share.


— Ron