A lightweight thread is a Thread

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Andrew Haley" <aph at redhat.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "David Lloyd" <david.lloyd at redhat.com>, "Alan Bateman" <Alan.Bateman at oracle.com>, "loom-dev"
> <loom-dev at openjdk.java.net>
> Envoyé: Mercredi 23 Octobre 2019 19:41:29
> Objet: Re: A lightweight thread is a Thread

> On 10/23/19 10:38 AM, Remi Forax wrote:
>> 
>>> De: "Andrew Haley" <aph at redhat.com>
> 
>>> On 10/22/19 5:27 PM, David Lloyd wrote:
>>>> One would still have to allow subclassing of threads though IMO, even
>>>> in the lightweight case.  This is enormously useful
>>>
>>> What is it about subclassing Thread that is enormously useful? I can't
>>> immediately think of any case where a scoped local couldn't achieve the
>>> same thing. Instead of
>>>
>>>   (MyFoo)Thread.current();
>>>
>>> you'd have
>>>
>>>   CurrentFoo.get();
>>>
>>> ... which would work in lightweight and heavyweight Threads. Is there
>>> something that definitely wouldn't work with this mechanism ?
>> 
>> all codes that already exist :)
>> 
>> being able to just do a super(..., /*lightweight*/ true) to use a lightweight
>> thread instead of an heavyweight one without having to rewrite all the client
>> code of that subclass of Thread that already exist.
> 
> I should have perhaps said "except legacy". If we're going to support all of
> the current properties of Thread we might as well cancel this project now.

While i agree that "all" is a dangerous word because those two kind of threads have not the same semantics so "all" is not something we can reach.
At the same, time every differences between a fat thread and a lightweight thread may result in a lot of head scratching for our users.

Retrofitting is at the same time a dark art and how you grow a language.

> 
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Rémi