A lightweight thread is a Thread

[Volkan Yazıcı]

If this (purposing j.l.Thread only within JSL) is the direction Java is
aiming for, why not deprecating it over time? If there are still cases
where such a deprecation would be too harsh and/or one might still need to
reach for them, doesn't this constitute the sufficient justification for
the explicit accessibility of this API? The bottom line of my comment is,
if they are gonna be exposed, let's embrace this as a fact and make it
explicit and accessible as a first-class citizen; otherwise, let them decay
over time and communicate this intent in the API too.

On Wed, Oct 23, 2019 at 3:47 AM Brian Goetz <brian.goetz at oracle.com> wrote:

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