A lightweight thread is a Thread

[Sergei Egorov]

> 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