A lightweight thread is a Thread

[Remi Forax]

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