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. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 27 févr. 2023 à 17:53, Mark Thomas <ma...@apache.org> a écrit : > FYI > > https://spring.io/blog/2023/02/27/web-applications-and-project-loom > > Written for $dayjob but the data is based purely on Tomcat and a trivial > web application. > > I think this could prove useful when we need discuss what to do with the > Loom module code. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
