A lightweight thread is a Thread

[seth lytle]

Do you have any data to back up this assertion ?

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