A lightweight thread is a Thread

Mark Raynsford org.openjdk at io7m.com
Tue Oct 22 15:43:00 UTC 2019


On 2019-10-22T16:19:15 +0100
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).

Nope, your first reading was pretty much it. For example, I might create
a pair of threads (T0, T1) to manage a pair of OpenGL contexts (C0, C1).
It's critical that I only make calls to C0 on T0, and calls to C1 on
T1. OpenGL drivers tend to react spectacularly if you get this wrong.

Additionally, it's important for performance reasons that T0 and T1 are
distinct kernel threads because, if I'm using multiple contexts, I'm
almost certainly doing it so that I can run long-running asynchronous
operations on one of them (such as uploading large textures), and
running rendering commands on the other. You can imagine the fun that
could result if T0 and T1 turned out to be lightweight threads both
being scheduled on a single kernel thread... "Why are my texture
uploads holding up my rendering commands?!".

Ron's reply indicated that I will still be able to get the necessary
control for the above.

-- 
Mark Raynsford | http://www.io7m.com



More information about the loom-dev mailing list