On Fri, Jul 6, 2012 at 2:40 PM, rex goxman <[email protected]> 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/ -- You received this message because you are subscribed to the Google Groups ruby-talk-google group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at https://groups.google.com/d/forum/ruby-talk-google?hl=en
