From: Mathieu Bouchard <matju@...>
Date: 2001-07-13T05:15:55+09:00
Subject: [ruby-talk:17750] Re: Pthreads


On Tue, 10 Jul 2001, Paul Prescod wrote:

> Let's say I call from Ruby into a C module that does a long
> computation. If my GUI is running on another "thread" that GUI will
> still lock up while the module is doing the computation. Right? For me,
> moving expensive compuations and network connections off of the GUI
> thread is a primary use for threads. 

Have you tried using Distributed Ruby or similar software? This is another
possible solution to that problem.

I say that because it isn't likely that Ruby has its thread model changed.
It's likelier to see a second Ruby interpreter support it (possibly on top
of JVM)



On Wed, 11 Jul 2001, Rogers Gene A Civ 96 CG/SCTOB wrote:

> Anyway, I digress.  I guess I will just study the code more, unless
> some one can tell me the exact data structures that I'd have to have
> in a thread specific memory hash?

To stick several Ruby interpreters in the same process you'd have to
ensure there are no global variables at all. But not only there are
several such variables in the Ruby interpreter itself, many extensions
also have global variables. The problem with threads is that is requires a
rework of any code that is designed with one thread in mind, even if that
only means removing all global state. So maybe my idea of multiple
interpreters per process is not quite good.

> Also matju are you talking about the sleep command not being granular
> enough? My understanding is that the sleep command in ruby even though
> it returns only integers still honors fractional parameters e.g.
> "sleep(.1)"

sleep(.1) would work, but sleep(.01) would only give about the same as
sleep(.1) if you have one very busy thread and a second one that does
mostly sleep. Unfortunately I usually need sleep(.01) to get a good
statistical sampling of program execution. 



matju