A lightweight thread is a Thread

[Volkan Yazıcı]

I have my doubts about that. For BlockHound (great tool BTW) one needs to
extend Thread's from reactor.core.scheduler.NonBlocking, hence yet another
use case for "new Thread". AFAIC, many libraries leverage similar Thread
labeling techniques to implement business logic based on the type of the
carrier Thread. Could one achieve a similar functionality without using
"new Thread"?

On Wed, Oct 23, 2019 at 8:57 AM Sergei Egorov <bsideup at gmail.com> wrote:

> > The numerous jars that implement a reactive and/or async and/or worker
> API are using a j.u.c.Executor instead of a plain old j.l.Thread on Maven
> Central ?
>
> FTR Project Reactor uses ExecutorService/ScheduledExecutorService, even for
> Schedulers.single() [1]
>
>
> [1]
>
> https://github.com/reactor/reactor-core/blob/9e03cfbdfe4e91aaae5a513fd2bf96a6ad7701de/reactor-core/src/main/java/reactor/core/scheduler/SingleScheduler.java#L69
>
> On Wed, Oct 23, 2019 at 8:52 AM Remi Forax <forax at univ-mlv.fr> wrote:
>
> > ----- Mail original -----
> > > De: "seth lytle" <seth.lytle at gmail.com>
> > > À: "Ron Pressler" <ron.pressler at oracle.com>
> > > Cc: "loom-dev" <loom-dev at openjdk.java.net>
> > > Envoyé: Mardi 22 Octobre 2019 19:04:05
> > > Objet: Re: A lightweight thread is a Thread
> >
> > > Do you have any data to back up this assertion ?
> >
> > The numerous jars that implement a reactive and/or async and/or worker
> API
> > are using a j.u.c.Executor instead of a plain old j.l.Thread on Maven
> > Central ?
> >
> > Rémi
> >
> > [1] https://mvnrepository.com/repos/central
> >
> > >
> > > Ron Pressler wrote:
> > >> People hardly use the Thread API directly *today*, relying instead on
> > >> j.u.c.Executor and the like.
> > >
> > >
> > >
> > > On Tue, Oct 22, 2019 at 11:07 AM Ron Pressler <ron.pressler at oracle.com
> >
> > wrote:
> > >>
> > >>
> > >>
> > >>
> > >> On 22 October 2019 at 15:23:09, Mark Raynsford
> > >> (org.openjdk at io7m.com(mailto:org.openjdk at io7m.com)) wrote:
> > >>
> > >> > On 2019-10-22T14:59:18 +0100
> > >> > Alan Bateman wrote:
> > >> > >
> > >> > > I think we are at the point where we are concluding that a
> > lightweight
> > >> > > thread should be represented by a Thread.
> > >> >
> > >> > Will this not have some nasty consequences when talking to native
> > code?
> > >> >
> > >> > For example, external graphics APIs such as OpenGL and Vulkan have
> > >> > strict restrictions on which threads can make calls into the APIs at
> > >> > any given time. If I'm calling native code, and I specifically
> create
> > >> > several individual threads for the purposes of doing so... How can I
> > be
> > >> > sure that each thread I've created corresponds to exactly one
> > operating
> > >> > system thread?
> > >>
> > >> By making it a heavyweight thread. When you create a Thread you choose
> > whether
> > >> it is scheduled by the OS (heavyweight) or by the JDK (lightweight).
> > >>
> > >>
> > >> >
> > >> > I feel like having a distinction at the type level between a Fiber
> and
> > >> > a Thread makes the difference in cost model explicit, even if
> there's
> > >> > no other API difference.
> > >> >
> > >> > I'm reminded of FreeBSD, for example, which used to have an m:n
> model
> > >> > for its own pthreads library, but eventually switched back to a 1:1
> > >> > model for performance reasons. I believe one of the issues was that
> > >> > over a decade of software had grown up around the idea that a thread
> > >> > had a particular cost model (in other words, was a heavyweight
> > >> > scheduling primitive) and that by changing the cost model to an m:n
> > >> > model ended up making most software perform poorly.
> > >>
> > >>
> > >> People hardly use the Thread API directly *today*, relying instead on
> > >> j.u.c.Executor and the like. This will likely remain the same with
> > lightweight
> > >> threads: People will use the structured-concurrency constructs to
> > manage them.
> > >>
> > >> Where Thread is used directly is in calls to Thread.currentThread
> (and,
> > to a
> > >> Lesser degree, the interruption mechanism, but that’s a separate
> > discussion).
> > >> This use is so pervasive that breaking assumptions about it would mean
> > little
> > >> existing code could run in lightweight threads.
> > >>
> > >> Now we get to have our cake and eat it too. Users will mostly interact
> > with
> > >> a new API, but those places where Thread is used extensively will
> > continue
> > >> working without change.
> > >>
> > >>
> > > > Ron
> >
>
>
> --
> Best regards,
> Sergei Egorov
>