On Fri, Jul 6, 2012 at 2:40 PM, rex goxman <lists / ruby-forum.com> wrote:
> Robert Klemme 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 am sorry, but you are wrong: I am not referring to that example.
You said you wanted to use green threads right from the start.  That's
a solution to a problem but not a problem.

> 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.

Actually it's not that simple.  A use case for green threads should
have specific properties that prevent usage of kernel threads or make
it less optimal for the case at hand.  I provided one such case (i.e.
platform does not support kernel threads) and I doubt there are so
many others.  That's what I asked for other use cases.  Of course
there are tons of use cases for concurrent processing but that's not
really the point.

But by now I believe the discussion has uncovered that what you really
want is pieces of code with not too much overhead.  Kirk gave an
example, Fibers might be another one.  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".

Regards

robert

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