Some Review of the EA build

Daniel López d.lopez.j at gmail.com
Tue Jun 30 16:30:28 UTC 2020


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.

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".

Just an idea,
D.

El mar., 30 jun. 2020 a las 16:02, Alan Bateman (<Alan.Bateman at oracle.com>)
escribió:

>
> > Did I miss any particular thing in the EA that I might take a look at?
> There are several people kicking the tyres right now (which is great).
> We are also hoping that some people will have the time to take it
> further and change an existing framework or application to use virtual
> threads, maybe go back to the "thread per request" model. This would
> help with validating (or not) whether the simple programming model (the
> one we all know!) will scale, it could help identify shortcomings in
> existing APIs, and maybe provide feedback on the performance and
> reliability.
>
> -Alan
>


More information about the loom-dev mailing list