On Fri, Sep 30, 2005 at 02:00:57PM +0900, Jeff McNeil wrote:
> Interesting. I'll do a bit of comparison work between that approach  
> and native Python "threading" support. I'd assume the dRB approach to  
> be slower.   Just out of curiosity, has any work been done towards  
> improving the threading system? The current system is great for  
> systems that might not fully support threading out of the box, but  
> I'd really like to see support for the POSIX threads at the system  
> level.
> 
> -Jeff

I hope we get native threads at some point.  It would be nice for
things like you're talking about.  I also hope that the threading
won't be like Python using a single global lock.

I've done quite a bit of work with Python and Python threading.
While it should be better at using a multi-processor
system and I/O of all forms than Ruby, its global interpreter
lock really reduces performance when running threaded code.  You
either have to use a process methodolgy like I described earlier
or write the threaded code in C/C++.

I have written several large systems in Python over the past 10
years and have written using Python threads, process level parallelism
and threaded C/C++ libraries using Python for the higher level
logic.  The C/C++ libraries proved to be by far the fastest.  The
same ideas could be used with Ruby.

Cavet, I haven't really used Python for about 2 years so I don't
know what the current state of the art is there.

A good point about Ruby threads is that they are rock solid
and can be used in much greater numbers than native threads
in many circumstances.

Rick

-- 
Rick Nooner
rick / nooner.net
http://www.nooner.net