On Aug 25, 2007, at 9:29 AM, Terry Poulin wrote:

>
> I've heard that Ruby 2.0 won't use Green Threads, so hopefully this  
> will
> change. I would assume the reason why Ruby uses Green Threads is to  
> try and
> maintain portability over efficientcy.

it's interesting to me that people assume green threads provide less  
performance advantage that native threads.  this is patently untrue:  
it all depends on your task!  to summarize

- if your task is cpu intensive AND you are on an SMP box AND you use  
many threads (aka lightweight processes) you will see a speed boost

- if your task is io/network bound and/or you are spawning a TON of  
threads then green threads will provide a speedup on any decent (aka  
not windoze) platform

consider these facts

- green threads are inexpensive to create compared to native threads
- green threads can help throughput a lot where io is concerened iff  
select is a good paradigm for scheduling activity (imagine many  
network connections)

- native threads are relatively expensive to create
- native threads have the same bottleneck on io that green threads  
have: you can physically only write to disk with the number of disk  
controllers you have and reading from sockets may still be limited to  
the speed of the person on the other end

green threads are good for something and native threads are good for  
somethings.  fortunately in ruby it's extremely easy to farm out  
tasks to another process and use ipc with

   slave = Slave.new{ Server.new }

so we get the best of both works if we want it.  people will miss  
green threads when they are gone - am i the only one who remembers  
not being able to stop java's native threads?

cheers.

a @ http://drawohara.com/
--
we can deny everything, except that we have the possibility of being  
better. simply reflect on that.
h.h. the 14th dalai lama