Some Review of the EA build

[Johannes Kuhn]

On 30-Jun-20 18:30, Daniel López wrote:
> Would it be feasible to add a flag to the ExecutorService factory methods
> so they return their virtual implementation counterparts for the sake of
> "brute force" testing?
> One of the main issues getting people to test is that a majority of people
> get to use threads/pools of threads through third party libraries,
> "applications servers" or containers that handle the creation of threads
> for them. So, even though many might be willing to have a go at it, the
> testing they can perform is quite limited. On the other hand many of those
> libraries etc. use the already existing methods so changing the
> implementation under the hood and returning virtual threads would require
> no new versions of those artifacts and would facilitate other people's
> testing. It won't be perfect testing, by far, and it might cause many false
> positives, but it might help detect some glaring issues before artifact
> creators get to update their code.

There are already a bunch of factory methods that should allow easy 
migration to Virtual Threads:

     ExecutorService exec = Executors.newVirtualThreadExecutor();
     ThreadFactory vtf = Thread.builder().virtual().factory();

As Virtual Threads are cheap (implementation looks simple, aside from 
saving/restoring the stack which is done in native methods), those 
executors are unbounded - it's easier to create a new Virtual Thread 
than to reuse existing ones. Which makes sense, as Virtual Threads reuse 
the carrier threads, so reusing virtual threads would duplicate that 
overhead.

And if you really need more control, you can create an ExecutorService 
from a ThreadFactory that uses a custom Executor. Just nesting is not 
possible - you can't use virtual threads as carrier for virtual threads.


> I, for example, usually develop web apps that create a handful of threads
> for various reasons, but the main "thread handler" in my day to day is
> Jetty, embedded as servlet container, so testing with changes in the code I
> control would yield very small benefits. OTOTH, if I can simply run the JVM
> with a flag that gets jetty to use virtual threads, I can test quite a bit
> more of my everyday life, right now. At least even if just to check that
> "if Jetty changed everything to virtual threads, it would not break".

With a quick google search for "jetty ThreadFactory" I found 
https://github.com/eclipse/jetty.project/issues/4121
Looking at the doc, it doesn't seem to provide a simple "take this 
ThreadFactory and start a new thread for every action that has to be 
done", which is the preferred way to use virtual threads. (Disclaimer: 
No idea how jetty works - maybe I should take a look).
There seems to be a DelegatingThreadPool [1], which can take a Executor 
- for example Executors.newVirtualThreadExecutor();.
Seems to be passed when creating a Server [2] - you might want to ask 
about more convenience constructors that accept an additional ThreadPool.

So, in most cases, using Virtual Threads is opt-in, which is fine - 
especially as virtual threads can't have certain characteristics like be 
a non-deamon thread.

- Johannes

[1]: 
https://www.eclipse.org/jetty/javadoc/current/org/eclipse/jetty/http/spi/DelegatingThreadPool.html
[2]: 
https://www.eclipse.org/jetty/javadoc/current/org/eclipse/jetty/server/Server.html#%3Cinit%3E(org.eclipse.jetty.util.thread.ThreadPool)