A lightweight thread is a Thread

[Brian Goetz]

Pretty much only the JUC implementation should be using the Thread API directly.  So if the assertion is wrong, we should still proceed as if it is right.  

> On Oct 22, 2019, at 1:04 PM, seth lytle <seth.lytle at gmail.com> wrote:
> 
> 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