From: Lothar Scholz <mailinglists@...>
Date: 2005-06-14T03:55:35+09:00
Subject: Re: Chip Multi-threading and the future

Hello Stephen,

SK> Hi Folks,

SK> Here is an article which is not about Ruby, but is about the future of
SK> computing (re multi-threading and chip multi-threading).

SK> http://www.tbray.org/ongoing/When/200x/2005/06/12/Threads

SK> I post this simply because Ruby's support for multi-threading is poor.
SK> If there is one area that needs improvement its multi-threading. When
SK> you read that article its even more apparent that Ruby needs improving
SK> on that front.

Correct. But look at "eval.c" and you know why we need a complete
reimplementation of ruby, there is absolutely no way to add this to
the existing code base. And when i hear Matz comments that YARV will
be integrated into eval.c this winter, then i doubt multi-threading
will be done right.

One problem we share with the python community :-)
They also need a complete python rewrite to handle more then one
thread at a time.

Another solution:

The problem could be easily solved if th OS producer will implement better
thread local store implementation. When a thread local variable has
the same speed as a global one we simply need to fix a few declarations.

And such a thread local store is easy to implement, just switch a few
memory pages inside the MMU when switching threads. Allmost zero
overhead and just a few lines in the thread scheduler. Of course there
must also some linker functionality in the program loader.

I think that this will come much earlier then a rewrite. I hope for
Longhorn as this will be also important for Microsoft.


-- 
 Best regards,                        emailto: scholz at scriptolutions dot com
 Lothar Scholz                        http://www.ruby-ide.com
 CTO Scriptolutions                   Ruby, PHP, Python IDE 's