On Fri, Jul 6, 2012 at 8:52 AM, Ryan Davis <[email protected]> wrote: > > On Jul 5, 2012, at 20:55 , Tony Arcieri wrote: > >> 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 > > 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 -- 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
