From: "Adam P. Jenkins" <thorin@...>
Date: 2005-07-29T07:06:01+09:00
Subject: Re: Ruby and threads

Yohanes Santoso wrote:
> "John Wells" <lists@sourceillustrated.com> writes:
> 
> 
>>Guys,
>>
>>Was looking through the forums at ruby-ide.com when I noticed the
>>following comment:
>>
>>"Unfortunately i can't use ruby for scripting/extending/implementing as
>>ruby does not work with multiple native threads and i already have one
>>ruby thread that is doing the background parsing."
>>
>>Can anyone elaborate on this?  How does it effect folks developing in
>>Ruby, and curiously, why does Python seem to support it and Ruby
>>doesn't?
> 
> 
> I can come up with only two significant downsides of green threading
> that ruby has:
> 
> 1. inability to use multiple cpus to run multiple threads,
> 2. blocked process.
> 
> (2) is usually caused by disk io waiting for disk readiness. this is
>     not monitorable in most unix (windows too?). the whole process
>     would block until the disk is ready.
> 
> (2) is also caused by certain functions in some c extension libraries.
> 
> python's supports for native threading effectively eliminates these
> two downsides, but also introduce another downside. threads executing
> python code would need to obtain the global interpretter lock. This
> means at any given moment, there is still only one thread executing
> python code. 

This certainly isn't an inherent problem with native threads; there is 
no reason in principle that an interpreted language couldn't let 
multiple threads execute simultaneously if the interpreter were written 
correctly.  If what you say is true, that only one Python thread can be 
executing at a time, then Python still can't really take advantage of 
multiple CPUS.

Adam

> In addition, the cost of acquiring the lock increases
> with the number of threads. But this setup eliminates (1) and (2).
> 
> YS.
> 
> 
>>Thanks for your insight!
>>
>>John
> 
> 
>