Re: Green threads in 1.9.* ?

On Mon, Jul 9, 2012 at 10:32 AM, rex goxman <[e-mail]> wrote:
> Robert Klemme wrote in post #1067956:
>> Eventually you can view any
>> object as a "green thread" in the way of that Erlang definition (which
>> I don't know) you gave: "pointer within the Erlang VM pointing off to
>> some chunk of code/memory inside the Erlang VM".
>
> What I'm wondering now (and someone who knows is welcome to answer) is
> that since we now know I have a totally different definition of "what
> constitutes green threads" than some here, does Ruby in fact have green
> threads according to my definition?  I was told "no" before, and
> accepted that answer, but the point is, I was probably told no by
> someone using a different definition than me.

Just as clarification: my definition of a "green thread" includes a
program counter (into code which records current position of execution
for the time the thread lies dormant) and a stack (which records the
call chain).  If you do not need to interrupt execution of a task you
do not need these and a simple reference to an object and method or
lambda is sufficient.

> Some questions someone can answer which will be helpful:
>
> 1. When a thread is created and used with the Thread class, does a new
> kernel thread or native thread have to be spawned to deal with it?

>= 1.9: yes
<1.9: no

> 2. Related to the first question, would it be common or the norm to have
> as many kernel threads spawned as threads created with the Thread class?
> What I'm asking is, say you make a loop which creates AND STORES a few
> hundred thousand threads from the Thread class.  Have you just created a
> few hundred thousand kernel or native threads, meaning I can go out to
> the OS and see these things in a process or thread viewer?  If it helps,
> assume this is either a 1 core processor, or a 2-4 core processor (in
> other words, the number of Threads you create are huge compared to the
> number of cores).

>= 1.9: yes, more correctly: at least as many.  The runtime or some library might create native threads of their own.

> If the answers are "yes" and "yes" I will say Ruby doesn't have green
> threads any longer.  If the answers are "no" and "no" I will say "ah,
> Ruby kept the green threads after all."

Well, but there are other things like Fiber and Continuation which
might be more appropriate in this case.  If you do not need to ensure
that execution of a task can be interrupted by another tasks execution
then you can simply use procs / lambdas (i.e. pieces of code to
execute) and throw them in a queue served by a thread pool.  That's
why we keep asking for the real use case you want to solve.

Cheers

robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/