A lightweight thread is a Thread

[David Lloyd]

On Tue, Oct 22, 2019 at 10:19 AM Alan Bateman <Alan.Bateman at oracle.com> 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).

It might be a good time to introduce a builder API for threads akin to
ProcessBuilder.  The constructors are already a bit out of hand!

One would still have to allow subclassing of threads though IMO, even
in the lightweight case.  This is enormously useful in application
server and framework environments (which is to say, a substantial
percentage of existing user bases).

-- 
- DML