Re: Green threads in 1.9.* ?

On Jul 5, 2012, at 14:22, rex goxman wrote:
> Eric Hodel wrote in post #1067586:
>> Ruby schedules use of the GVL for threads created by the ruby VM.
>>=20
>> A Ruby thread may release the GVL to run non-ruby code.

For these answers I am ignoring Windows.  You can probably treat "POSIX =
thread" as the equivalent userland threads on Windows, but don't take my =
word for it.

> What is a ruby thread?

A thread spawned from ruby.  Non-ruby threads can be spawned by other =
libraries.  For example, if you've embedded ruby in a game engine the =
game engine can have many of its own threads which ask ruby threads to =
do work.

> A green thread?

Any program that manages thread creation and scheduling for itself =
without use of the OS uses green threads.

> A kernel thread?

The most literal definition is a thread that runs in, and only in, the =
kernel.  You can ignore them for most purposes since you don't have any =
direct control over when or how many are created by your process (this =
is true for all programs, not just ruby programs).  I think that most =
frequently, kernel threads are mapped 1:1 to userland threads, but this =
may vary between different OSs.

At one point FreeBSD had multiple pthread implementations you could link =
in your program.  One had 1:1 mapping between kernel threads and =
userland threads, one had 1:N mapping (one kernel thread per process) =
and one M:N mapping (multiple userland threads per kernel thread).

Userland threads are what userland programs run.  The POSIX thread API =
(pthread) handles userland threads and takes care of spawning the =
threads, allocating stack space for them, etc.  Depending upon the =
mapping to kernel threads they may be scheduled from userland or from =
the kernel.  (I think, most frequently, from the kernel.)

> A green thread mapped to a kernel thread?

Since a green thread is scheduled from within a program the kernel has =
no knowledge of it so they won't be mapped.

> The depiction at the link somewhere above seems to suggest it is a =
green=20
> thread which is mapped one-to-one to a kernel thread.

Since pthreads typically make some communication with the kernel it =
isn't correct to call them green threads.  It's possible to have a =
pthread library that makes no communication with the kernel (a library =
similar to FreeBSD's 1:N thread library could do this), but in practice =
I doubt this happens.  It's difficult for a thread library to schedule a =
process' threads on multiple CPUs without some communication with the =
kernel.

> Some here suggest there is no such thing, just kernel threads.  I will =
assume it is a kernel thread unless you say otherwise.

I think what they describe as "kernel threads" I call "userland =
threads".  The OS often has its own threads to perform OS tasks such as =
userland scheduling, handling interrupts, polling for IO from hardware, =
etc.  I don't wish to confuse the two.

Digging in further to thread.c, the GVL is not directly part of userland =
thread scheduling or ruby thread scheduling, it's just a lock around the =
ruby VM that allows a thread to use the ruby VM.  (If a thread calls =
methods in the Ruby VM without the GVL it will likely cause corruption =
and crashes.)  Ruby uses pthread API to switch threads so it's up to the =
OS which threads get run.

Ruby will interrupt threads that have run for "too long" and allow the =
OS to schedule another thread.  This is all performed through pthread =
mutexes and condition variables.  (Perhaps I'm missing it, but I'm no =
longer seeing a list of threads waiting to run as I recall 1.8 having =
which is a requirement for a green thread implementation.)