single thread executor

[Alan Bateman]

On 07/09/2020 12:39, Ron Pressler wrote:
> There are some circumstances in which you may want a custom scheduler, but
> InetAddress.getByName isn’t one of them. Occasionally blocking the OS thread
> is fine; it should only be a problem if done *very* frequently. The work-stealing
> scheduler should automatically smooth over such issues (and in the case of
> getByName it might even automatically increase the size of the worker thread
> pool). If it doesn’t, and you see some cases where throughput is unsatisfactory,
> please report them to this list. Custom schedulers are not the solution for
> such cases, certainly not by default. They should be reached for only in much
> more "special" circumstances.
>
Just to add to Ron's comment but you might find it easier to just run 
with -Djdk.defaultScheduler.parallelism=1 if your goal is to just 
experiment with a single carrier thread and see what happens.

InetAddress.getByXXX is work in progress. In the current EA builds it 
uses the ForkJoinPool "managed blocker" facility so parallelism may be 
increased when it needs to do a lookup (that is what Ron implies above). 
There is ongoing work in the JDK sandbox on a provider mechanism for 
name service lookup so that implementations that a more virtual thread 
friendly can be deployed. There is also a prototype resolver that 
supports files and/or DNS in the sandbox but it might be that we don't 
propose to bring that into the main line.

-Alan