On 27/02/2023 18:02, Romain Manni-Bucau wrote:> Le lun. 27 févr. 2023 à
18:38, Mark Thomas <ma...@apache.org> a écrit :
On 27/02/2023 17:09, Romain Manni-Bucau wrote:
Hi,
AFAIK loom or a standard thread pool are exactly the same except when you
use loom you need to ensure you pass the contextual executor to use
(scheduler in the API IIRC) otherwise the Thread.startVirtualThread will
use the global JVM one (so you use 2 thread pools which is unintended in
general and for tomcat which is multi-webapp can be an issue in some
contexts).
So overall the main benefit is to enable to use the contextual thread
pool
owner to execute any banalized task.
This is a great advantage and shouldnt touch other applications (which
stays in a thread pool executor) so it sounds hurtless to auto switch to
loom when possible.
However it means you do not use LoomExecutor but a configured loom
executor
(default works while only using loom friendly and not blocking code but
as
soon as you will break that statement it will not work anymore).
Ideally it means using java/lang/ThreadBuilders(Executor) to configure it
and pass a standard executor to it.
Hope it makes sense.
Not really, no. There is no thread pool with Loom.
There is an implicit default fork join pool, see
https://github.com/openjdk/loom/blob/e9f05191c306b2af9d91397f8a5bfffd948e6d69/src/java.base/share/classes/java/lang/VirtualThread.java#L1081
.
It defaults to the number of proc.
Max is 256 and min number of proc/2.
Similarly there is a scheduled pool of 1 by default for background tasks.
Oh. The carrier threads. That clarifies your meaning somewhat. There is
a notable difference between that and the standard thread pool which was
evident in the tests in the blog post. The blocking queue used for the
work queue on the standard thread pool suffers from contention much more
than Loom's work stealing queue.
Yes, putting virtual threads into a standard thread pool is pointless
(and probably has a negative performance impact too).
Tomcat has taken the simple approach for this for now:
https://github.com/apache/tomcat/blob/main/modules/loom/src/main/java/org/apache/catalina/core/LoomExecutor.java
Whether we'll need to worry about separate pools of carrier threads - or
configuration of that pool / those pools - is TBD.
I'm still not sure what you mean by "default works while only using loom
friendly and not blocking code".
So using loom without caution is using a JVM (with its classloader side
effect) thread pool which is enabled for JVM continuations, nothing more.
What class loader effects? The context class loader should be picked up
from the virtual thread.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
