A lightweight thread is a Thread

[Sergei Egorov]

There is no such requirement in BlockHound, to extend/implement anything.
One can provide a Thread instance predicate to mark it
blocking/non-blocking.

Soon we will support dynamic predicates too, so that the flag is not cached
per thread.

On Wed, 23 Oct 2019 at 12:45, Volkan Yazıcı <volkan.yazici at gmail.com> wrote:

> I have my doubts about that. For BlockHound (great tool BTW) one needs to
> extend Thread's from reactor.core.scheduler.NonBlocking, hence yet another
> use case for "new Thread". AFAIC, many libraries leverage similar Thread
> labeling techniques to implement business logic based on the type of the
> carrier Thread. Could one achieve a similar functionality without using
> "new Thread"?
>
> On Wed, Oct 23, 2019 at 8:57 AM Sergei Egorov <bsideup at gmail.com> wrote:
>
>> > 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
>>
> --
Best regards,
Sergei Egorov