single thread executor

[Miguel Ping]

Thanks for the reply. InetAddress.getByName was just an example (even more
because DNS resolution is not really simple), I agree that most of the time
you shouldn't bother and virtual threads would work just fine.

Apologize in advance if the questions sound dumb, it's just that I find
that I learn the most when trying to do unorthodox or stupid things.
I acknowledge that the main idea behind loom is just use a
newUnboundedExecutor and be done with it, it should just work for 99% of
the scenarios.


On Mon, Sep 7, 2020 at 1:30 PM Alan Bateman <Alan.Bateman at oracle.com> wrote:

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