On Fri, Jul 6, 2012 at 8:52 AM, Ryan Davis <ryand-ruby / zenspider.com> wrote:
>
> On Jul 5, 2012, at 20:55 , Tony Arcieri wrote:
>
>> On Thu, Jul 5, 2012 at 8:24 PM, rex goxman <lists / ruby-forum.com> 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/