A lightweight thread is a Thread

[Mark Raynsford]

On 2019-10-22T14:59:18 +0100
Alan Bateman <Alan.Bateman at oracle.com> 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?

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.

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