Hello guys,
This is the first time I am working with threads and so far it gave me a
good result in the speed of my code, using Ruby 1.8.6 in the native Mac OS
X distribution. By I read in the book "The Ruby Programming language" that
the threads in the standard "C" Ruby 1.8.6 are not real OS threads and
they all share the same main Ruby thread. I have read also that JRuby
implements real OS threads.
My code triggers more than 200 threads each of them with one private
connection to a MySQL database.
Would it be a real advantage to use JRuby in this scenario?
Thanks,
Guillermo
Hello guys,
This is the first time I am working with threads and so far it gave me a
good result in the speed of my code, using Ruby 1.8.6 in the native Mac OS
X distribution. By I read in the book "The Ruby Programming language" that
the threads in the standard "C" Ruby 1.8.6 are not real OS threads and
they all share the same main Ruby thread. I have read also that JRuby
implements real OS threads.
Read this good document about Ruby threading:
The Futures of Ruby Threading
My code triggers more than 200 threads each of them with one private
connection to a MySQL database.
Would it be a real advantage to use JRuby in this scenario?
Well, Ruby threads are "green" threads, this is: they only exist into the Ruby
process but not for the OS so all the threads runned into a Ruby process
share the same processor (you get not advantage of a multiprocessor
computer).
JRuby uses the Java virtual machine, and that uses real OS threads, but that's
all I know 
···
El Martes, 24 de Junio de 2008, Guillermo.Acilu@koiaka.com escribió:
--
Iñaki Baz Castillo
If you would like your app to take advantage of multiple cores without the complexity of cross-process communication, then JRuby would probably be a great choice.
- Charlie
···
Guillermo.Acilu@koiaka.com wrote:
Hello guys,
This is the first time I am working with threads and so far it gave me a good result in the speed of my code, using Ruby 1.8.6 in the native Mac OS X distribution. By I read in the book "The Ruby Programming language" that the threads in the standard "C" Ruby 1.8.6 are not real OS threads and they all share the same main Ruby thread. I have read also that JRuby implements real OS threads.
My code triggers more than 200 threads each of them with one private connection to a MySQL database.
Would it be a real advantage to use JRuby in this scenario?
Same problem. But i solve it as DRb + fork.
···
On Tue, Jun 24, 2008 at 6:29 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
El Martes, 24 de Junio de 2008, Guillermo.Acilu@koiaka.com escribió:
Hello guys,
This is the first time I am working with threads and so far it gave me a
good result in the speed of my code, using Ruby 1.8.6 in the native Mac OS
X distribution. By I read in the book "The Ruby Programming language" that
the threads in the standard "C" Ruby 1.8.6 are not real OS threads and
they all share the same main Ruby thread. I have read also that JRuby
implements real OS threads.
Read this good document about Ruby threading:
The Futures of Ruby Threading
My code triggers more than 200 threads each of them with one private
connection to a MySQL database.
Would it be a real advantage to use JRuby in this scenario?
Well, Ruby threads are "green" threads, this is: they only exist into the Ruby
process but not for the OS so all the threads runned into a Ruby process
share the same processor (you get not advantage of a multiprocessor
computer).
JRuby uses the Java virtual machine, and that uses real OS threads, but that's
all I know
--
Iñaki Baz Castillo
Could you please give a tip of your solution using Drb + fork?
···
El Martes, 24 de Junio de 2008, Zhukov Pavel escribió:
Same problem. But i solve it as DRb + fork.
--
Iñaki Baz Castillo
core app starts DRb server with self as front object. then, i fork
'plugins' that connect to core app and "register" youself in core's
@plugin list.
Modified signal system provide communication between processes.
if you interested:
Google Code Archive - Long-term storage for Google Code Project Hosting. #core class
Google Code Archive - Long-term storage for Google Code Project Hosting.
#all plugins should be based on it
Google Code Archive - Long-term storage for Google Code Project Hosting.
#modified signal system
···
On Tue, Jun 24, 2008 at 7:10 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
El Martes, 24 de Junio de 2008, Zhukov Pavel escribió:
Same problem. But i solve it as DRb + fork.
Could you please give a tip of your solution using Drb + fork?
--
Iñaki Baz Castillo
Thanks a lot, it seems interesting.
···
El Martes, 24 de Junio de 2008, Zhukov Pavel escribió:
core app starts DRb server with self as front object. then, i fork
'plugins' that connect to core app and "register" youself in core's
@plugin list.
Modified signal system provide communication between processes.
if you interested:
Google Code Archive - Long-term storage for Google Code Project Hosting. #core class
Google Code Archive - Long-term storage for Google Code Project Hosting.
#all plugins should be based on it
Google Code Archive - Long-term storage for Google Code Project Hosting.
#modified signal system
--
Iñaki Baz Castillo