[andersmurphy]

(author here) From what I've read, other than documentation saying they shouldn't be pooled, is that by disign they are meant to run and then get garbage collected. There's also some overhead in managing the pool. If someone has a deeper understanding of virtual threads I'd love to know why in more detail.

As to why use a semaphore over a thread pool for this implementation? A thread pool couples throughput to the number of running threads. A semaphore lets me couple throughput to started tasks per second. I don't care how many threads are currently running, I care about how many requests I'm making per second. Does that make more sense?

[pron]

Pooling virtual threads has no upside and potentially a bit of downside: 1. You hang on for unused objects for longer instead of returning them to the more general pool that is the GC; 2. You risk leaking context between multiple tasks sharing the thread which may have security implications. Because of these and similar downsides you should only ever pool objects that give you benefit when they're shared -- e.g. they're expensive to create -- and shouldn't pool objects otherwise.

[amgreg]

Thank you for this, but thank you especially for virtual threads! They are awesome!

Is point 2 a virtual-thread only risk, or would we incur it with regular threads too?

[pron]

Thank you! You incur this risk when pooling any kind of thread, too, but with platform threads at least pooling makes sense because they're costly, so you just need to be careful with thread locals on a shared thread pool. Not needing to share threads and potentially leak context is a security advantage of virtual threads.

[andersmurphy]

Thank you for the explanation and for all the hard work on bringing virtual threads to the JVM. It's a really awesome feature.