A lightweight thread is a Thread

[Elias N Vasylenko]

This strikes me as similar to the trouble in the Valhalla project in
finding where inline types fit into the class hierarchy.

IIRC they went through a similar permutation of prototypes, and arrived
at a similar conclusion. Just as how lightweight and heavyweight
threads should both be Threads, they hope that both inline types and
reference types can simply be Objects. 

This choice also comes with similar drawbacks. Just as inline types
don't want to be burdened with all the state and behaviour baggage of
the Object class, so it is for fibers wrt the Thread class.

Does this seem like a coherent comparison?

Well, my point is that one of the solutions which they are exploring is
to make Object an abstract class, so that there can be ReferenceObject
and InlineObject types can provide their own implementations
independently.

https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2019-April/000980.html

As described in that thread, this means that existing instances of "new
Object" and "extends Object" will have to be transparently rewritten,
but this isn't necessarily an impossible goal.

Of course it's possible that this will all just be special-cased by the
compiler and VM, or that they will end up going down a different road
altogether... But if some more general mechanism were provided to
evolve API in this way (i.e. to make an existing concrete class
abstract without breaking backwards compatibility) could this apply to
you down the line?

    // declares HeavyweightThread as the canonical
    // concrete implementation so that "new Thread"
    // and "extends Thread" defer to it.
    sealed abstract class Thread {} 
    class LightweightThread extends Thread {}
    class HeavyweightThread extends Thread {}

LightweightThread and HeavyweightThread don't need to be exposed in the
API of course, they may just an implementation detail.

Anyway it's just a bit of curiosity and a thought for the future. Of
course I'm not suggesting making any design decisions based on
something so speculative.

On Tue, 2019-10-22 at 16:19 +0100, Alan Bateman wrote:
> On 22/10/2019 15:22, Mark Raynsford wrote:
> > :
> > 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?
> The existing constructors work as before and this project might also 
> introduce static factory methods to create heavyweight threads. But 
> maybe you mean something else? If you mean there may be lightweight 
> threads wanting to do OpenGL calls then you'll probably have your
> own 
> scheduler over a pool of heavyweight threads that are allowed to do
> the 
> graphics ops. When this project is further along then we might have
> to 
> add to JNI (we're staying away from that just now because Project
> Panama 
> is making progress and that may be more important).
> 
> -Alan