Green threads in 1.9.*?

Ruby
21

Am 05.07.2012 um 18:34 schrieb Tony A. [email protected]:

On Thu, Jul 5, 2012 at 6:38 AM, rex goxman [email protected] wrote:

You might say “do that with a kernel thread.” But what if I want to
spawn this thread over and over again in a tight loop? I don’t want or
need the monstrous overhead of a kernel thread here. I just want a
green thread.

If the time it takes to spawn a thread is really too much, use a thread pool.

Couldn’t a similar design be achieved by using Fibers and a Thread pool
that grabs work from a list of ready Fibers?

22

On Thu, Jul 5, 2012 at 6:38 AM, rex goxman [email protected] wrote:

This is a crappy example, but say you need to do some
calculation which might fail or even crash, but you don’t want (or need)
to check the inputs to the calculation, or wrap the thing up in an error
catching mechanism, or anything of this nature. You just want to
calculate it, and if it works, fine, and if it doesn’t (or even crashes)

  • fine, your main program continues to run. So spawn a green thread to
    run the calculation. If it works, great. If it crashes, who cares?

You want threads as a way to silently swallow exceptions? o_O I’m going
to
go out on a limb and say that’s a terrible application for threads…

You might say “do that with a kernel thread.” But what if I want to

spawn this thread over and over again in a tight loop? I don’t want or
need the monstrous overhead of a kernel thread here. I just want a
green thread.

If the time it takes to spawn a thread is really too much, use a thread
pool.

23

Tony A. wrote in post #1067551:

You want threads as a way to silently swallow exceptions? o_O I’m going
to
go out on a limb and say that’s a terrible application for threads…

  1. Tell that to Erlangers.

  2. I did preface that with

This is a crappy example, but …

In short, no, that’s not really my application for them, just know that
I have one.

If the time it takes to spawn a thread is really too much, use a thread
pool.

You seem to be of the mindset that there couldn’t possibly be any reason
or circumstance to want to use green threads. Okay, “whatever” I guess.

24

On Thu, Jul 5, 2012 at 10:26 AM, rex goxman [email protected]
wrote:

  1. Tell that to Erlangers.

I assure you, I am quite familiar with Erlang:

Whenever an OTP process (e.g. gen_server, gen_event) crashes, the reason
for the crash is meticulously logged by the OTP logging framework. This
is
pretty much the only way to debug asynchronous behaviors, as if the
exceptions are swallowed by default you have no outward indication of
what
happened.

Erlang provides a great example of a system that is the exact opposite
of
the one you are proposing.

25

On Thu, Jul 5, 2012 at 9:45 AM, Florian G.
[email protected]wrote:

Couldn’t a similar design be achieved by using Fibers and a Thread pool
that grabs work from a list of ready Fibers?

Fibers are pinned to the threads they are created in and cannot be
resumed
in other threads

26

Tony A. wrote in post #1067563:

Erlang provides a great example of a system that is the exact opposite
of
the one you are proposing.

  1. I have proposed no system. I have stated that I’d like to use green
    threads, and asked if ruby still had them available.

  2. Erlang uses green processes, emphasis on ‘green’.

27

On Jul 4, 2012, at 18:33, Tony A. wrote:

On Wed, Jul 4, 2012 at 5:11 AM, Xavier N. [email protected] wrote:

Then, behind the scenes, they are mapped to native threads in MRI 1.9 and
JRuby. One-to-one. In the case of MRI there’s a GIL. I guess technically a GIL
does not mean that MRI is doing the scheduling, it means MRI is holding a lock,
but the kernel schedules the native thread (because it is native). Maybe there’s a
gray area in the definition of green thread here, I don’t know.

MRI is still doing the scheduling in 1.9. It runs a timer thread that interrupts
running threads after a certain amount of time so waiting threads can run. This
way a single thread doing some computationally intensive operation doesn’t
monopolize the entire VM.

A more accurate picture of 1.9 is:

The OS schedules threads to run on CPUs.

The ruby VM has a global lock that only allows one thread to run ruby
code at a time (the GVL). The GVL is also held for execution inside C
extensions unless the author releases the GVL (most extensions release
the GVL for some part of their operation).

Ruby schedules use of the GVL for threads created by the ruby VM.

A Ruby thread may release the GVL to run non-ruby code. An example
would be performing a long calculation such as interacting with a DB,
processing zlib streams, XML parsing with libxml2, etc. Such tasks
don’t need to communicate with the ruby VM so they can be running on
separate CPUs at the same time as the ruby VM.

A Ruby thread will release the GVL when it performs a blocking operation
such as IO or other system calls.

So the OS and the ruby VM cooperate on thread scheduling. If multiple
ruby threads do not need the GVL to run the OS does the majority of the
scheduling. If multiple ruby threads do need the GVL ruby does the
majority of the scheduling.

28

On Thu, Jul 5, 2012 at 1:22 PM, Eric H. [email protected] wrote:

ruby threads do not need the GVL to run the OS does the majority of the
scheduling. If multiple ruby threads do need the GVL ruby does the
majority of the scheduling.

This would make a good FAQ entry, I think. Thanks, Eric.

Jos

29

rex, why are you still here? You don’t want to tell your actual reasons
for using green threads, you don’t want to hear alternative solutions,
and the responses seem to annoy you.

Then what’s the point of this whole discussion? The original question
seems to be answered by now.

30

rex goxman [email protected] wrote:

Anyway, to the point. I’d like to use green threads (NOT kernel
threads) in a Ruby program I’m writing. There is no reason for me to
use kernel threads, and every reason to use green ones.

You could try linking Ruby with GNU pth (or GNU nPth). I think pth
comes with pthreads stubs, so maybe you can get that working (and
report back your experiences :slight_smile:

I suspect pth will conflict with Fibers, however.

If not available, are there any alternatives? I checked into fibers,
but they are not appropriate for what I want because if an exception
happens, it happens in the “main thread” I am executing, which I don’t
want.

I know you don’t like fibers, but the “neverblock” gem uses Fibers
transparently under 1.9 to provide green threads. However, I’m
not sure how active “neverblock” development is these days.

31

On Thu, Jul 5, 2012 at 12:31 PM, rex goxman [email protected]
wrote:

  1. I have proposed no system. I have stated that I’d like to use green
    threads, and asked if ruby still had them available.

Your suggested use case for green threads was firing off background jobs
that may or may not break, with zero interest as to if they complete
successfully. This is not what Erlang does. Erlang/OTP provides
extensive
reporting of all failures of any OTP components.

At least, that seems to be what you’re suggesting here. Please correct
me
if I’m wrong:

This is a crappy example, but say you need to do some

32

I’d also like to reiterate that Erlang is doing the right thing here and
that silently swallowing errors in an asynchronous concurrent system
(which
is what you’re proposing) is an extremely bad idea. In an asynchronous
system, the error log is your only tool for understanding what’s broken
and
where. You will most certainly want to capture and log all errors, not
silently ignore them, or else you will have no visibility into if your
asynchronous background tasks are working or not.

33

Eric H. wrote in post #1067586:

Ruby schedules use of the GVL for threads created by the ruby VM.

A Ruby thread may release the GVL to run non-ruby code.

What is a ruby thread? A green thread? A kernel thread? A green
thread mapped to a kernel thread?

The depiction at the link somewhere above seems to suggest it is a green
thread which is mapped one-to-one to a kernel thread. Some here suggest
there is no such thing, just kernel threads. I will assume it is a
kernel thread unless you say otherwise.

Eric W. wrote…

I know you don’t like fibers, but the “neverblock” gem uses Fibers
transparently under 1.9 to provide green threads. However, I’m
not sure how active “neverblock” development is these days.

Actually I like fibers quite a bit, I just didn’t think they were
applicable in this particular circumstance. I can check into neverblock

  • thanks.
34

Tony A. wrote in post #1067609:

Your suggested use case for green threads was firing off background jobs
that may or may not break, with zero interest as to if they complete
successfully.

I’m not sure if you are someone with reading-comprehension issues, or a
troll. I will state (again) that I threw a “crappy” example out there
off the top of my head as a reason someone might want green threads. I
did this because some people seem to lack the creativity to come up with
use cases themselves, which are plentiful and abound. In hindsight, it
seems to have been a serious mistake on my part to have done this, since
you continue to ignore the fact that I stated it was a “crappy” example
and continue to inexplicably seize upon what I wrote as some opportunity
to “hammer” me.

Having said that, I stand by what I said. You might want to fire off
background jobs that may or may not break, with zero interest as to if
they complete successfully.

This is not what Erlang does. Erlang/OTP provides
extensive
reporting of all failures of any OTP components.

Erlang “does” whatever you want it to do, bro. If you want process
supervision, extensive reporting of all failures, blah blah, it is
there. If you don’t want that (and in many cases, you don’t), you don’t
have to use it. As with anything, it depends on your application and
what you want to do with it.

35

On Thu, Jul 5, 2012 at 8:24 PM, rex goxman [email protected] wrote:

I’m not sure if you are someone with reading-comprehension issues, or a
troll. I will state (again) that I threw a “crappy” example out there
off the top of my head as a reason someone might want green threads. I
did this because some people seem to lack the creativity to come up with
use cases themselves, which are plentiful and abound. In hindsight, it
seems to have been a serious mistake on my part to have done this, since
you continue to ignore the fact that I stated it was a “crappy” example
and continue to inexplicably seize upon what I wrote as some opportunity
to “hammer” me.

So in other words, you don’t have a use case for green threads

36

Tony A. wrote in post #1067610:

I’d also like to reiterate that Erlang is doing the right thing here and
that silently swallowing errors in an asynchronous concurrent system
(which
is what you’re proposing) is an extremely bad idea.

If you are saying that there never has been nor never will be a use case
for anyone on the planet where they might want to silently swallow
errors in an asynchronous concurrent system, and that to even
contemplate such is always a bad idea, then you, sir, are an idiot.

37

On Jul 5, 2012, at 20:55 , Tony A. wrote:

So in other words, you don’t have a use case for green threads

Do you HAVE to have the last word? Is that what this is?

There are plenty of use cases for green threads, and YOU know that. The
fact that Rex is not telling you his means nothing. Stop being a
jackass.

38

On Fri, Jul 6, 2012 at 8:52 AM, Ryan D. [email protected]
wrote:

you continue to ignore the fact that I stated it was a “crappy” example
and continue to inexplicably seize upon what I wrote as some opportunity
to “hammer” me.

So in other words, you don’t have a use case for green threads

Do you HAVE to have the last word? Is that what this is?

I think the point is, that as long as we do not know rex’s real use
case we cannot come up with proper suggestions for alternative
solutions to green threads. So far rex provides a solution he wants
to use but I cannot really see the reasoning behind it.

Btw. even green threads come at a price and firing off a lot of tasks
by just creating threads (whatever color) when the task appears is not
likely going to work out well for large numbers of concurrent tasks.
In this case one would need some form of thread pool with a queue
anyway. And then the difference between green and kernel thread
creation is irrelevant anyway.

There are plenty of use cases for green threads, and YOU know that. The fact
that Rex is not telling you his means nothing. Stop being a jackass.

Actually I have doubts that there are so many use cases for green
threads. Off the top of my head only platforms which do not support
kernel threads come to mind. I’d love to hear more and especially the
case rex has in mind.

Other than that the overhead in terms of memory and CPU for creating a
kernel thread isn’t too big nowadays. And from a global perspective
which covers operating system as well as hardware trends Matz’s
decision to go for kernel threads is wise because that will eventually
give us better performance (once GIL is gone).

Kind regards

robert

39

On Jul 6, 2012, at 6:40 AM, rex goxman [email protected] wrote:

Robert K. wrote in post #1067663:

So far rex provides a solution he wants
to use but I cannot really see the reasoning behind it.

Sigh. I did not provide a “solution I want to use.” I provided a
CRAPPY EXAMPLE off the top of my head that was advertised as a CRAPPY
EXAMPLE before giving the CRAPPY EXAMPLE.

Hey Rex,

I think you misunderstood here. You said you wanted to use green threads
as a solution but haven’t stated a problem i.e. you stated the solution
you want.

I think there’s a couple of different voices in this thread, but one
recurring one is asking for your use case so that they can help come up
with an alternate solution. It doesn’t sound like you are looking for an
alternate, though, just that you’re surprised green threads were removed
entirely.

Jams

40

Robert K. wrote in post #1067663:

So far rex provides a solution he wants
to use but I cannot really see the reasoning behind it.

Sigh. I did not provide a “solution I want to use.” I provided a
CRAPPY EXAMPLE off the top of my head that was advertised as a CRAPPY
EXAMPLE before giving the CRAPPY EXAMPLE.

I do not intend to divulge any real use cases for green threads because
they are intuitively obvious, apparent, easy to find or dream up for
one’s self, and the literature is abundant and easily available. It’s
sort of like being asked to give a use case for a hammer. I’m not here
to educate. If people want education, it’s up to them to get it, not up
to me to provide it.

Use cases for green threads aren’t controversial, and there is no debate
on it anywhere that I’m aware of… except perhaps here I guess. I
don’t intend to debate whether or not green threads can be a good thing
and whether there are many use cases for them any more than I wish to
debate whether 2 + 2 = 4.

Now, whether Ruby wants to deploy and maintain a green threads solution
or not is another issue entirely, completely separate from the issue of
whether “green threads are good,” or “green threads have many valid use
cases.” The answers to the latter two issues are an unequivocal ‘yes.’
The answer to the former could be anything, and rightly or wrongly so.

Ruby might have good reasons or not so good reasons for wanting or not
wanting to maintain green threads. I don’t care, and I’m not here to
comment on that either way. While I did say I was somewhat surprised
that Ruby would ditch green threads altogether vs. keeping them around
and deploying kernel threads alongside, there may very well be good
reasons for such a decision, not least of which may simply be limited
resources to devote to a threading implementation, and thus a need to
simply pick one and go with it (just a guess).

And from a global perspective
which covers operating system as well as hardware trends Matz’s
decision to go for kernel threads is wise because that will eventually
give us better performance (once GIL is gone).

Perhaps I have a clue here as to some of the… “interesting” responses
I have received on this. Perhaps it’s a classic case of an “outsider”
being perceived as coming into a community and criticizing the leader of
the community.

If so, let me be clear. I have said nothing regarding Matz, nor of his
decision to go for kernel threads, nor the wisdom of that decision.
Whether green threads are “good” or not, and whether Matz made a wise
decision in ditching them for kernel threads, is two separate issues.
In other words, it is possible that “green threads are good” and “Matz
made a great decision and is a genius” are both true.