single thread executor

[Ron Pressler]

Your questions are not dumb at all, and they help us understand which
concepts are confusing as well as give me the opportunity to give some
general advice to other readers.

Indeed, your last response hints at one such confusion:

> just use a newUnboundedExecutor and be done with it

newThreadExecutor (the new name for newUnboundedExecutor) is what you
should use *regardless* of the scheduler used for virtual threads. It
is an executor build *on top* of virtual threads, while the custom
scheduler you want to experiment with is used *underneath* virtual
Threads, as part of their implementation. It replaces the kernel 
scheduler used by platform thread, while newThreadExecutor replaces
various Executors, normally thread pools, optionally used to manage 
threads today. So newThreadExecutor is also optional (though recommended),
but it is completely orthogonal to the choice of virtual thread scheduler.

That’s why the custom scheduler is passed to Thread.Builder.virtual,
and is not related to which Executor, if any, you choose to use to
manage the resulting virtual threads.

— Ron




On 7 September 2020 at 14:25:56, Miguel Ping (miguel.ping at gmail.com(mailto:miguel.ping at gmail.com)) wrote:

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