Re: state of threads in 1.9

On Nov 15, 2007 7:33 AM, Eric Hodel <[e-mail]> wrote:
> On Nov 14, 2007, at 11:18 , Bill Kelly wrote:
> > From: "Berger, Daniel" <[e-mail]>
> >> Really, the only time that I've needed native thread support is for
> >> extending existing C libraries. I don't see the upside for general
> >> concurrency, since we're not getting multi-core support anyway.
> >
> > No multi-core support... ever?
>
> No multi-core support yet.
>
> > I had presumed native threads were a step in that direction.  (No?)
>
> It is.  We're going from one thread to many threads with a global
> lock.  Fine-grained locking is both expensive and hard.  It has taken
> FreeBSD years to move from a global lock to fine grained locking.
>

It is really bad news for me. My application is really heavy threaded
and even with only 2 or 4 cores I wanted to use them (you may think
that Ruby is not the right language for that anyway ...). I guess I
can use C++ and Qt library (my option number two after ruby,
suggestions accepted)



> > What I've been looking forward to is embedding Ruby in a multi-
> > threaded C++ app, and someday being able to have any C++ thread
> > call directly into the Ruby interpreter.
>
> If you've embedded ruby, you may be able to have multiple C++ threads
> running and one ruby thread running (out of N ruby threads).

So, you mean having all the threads code but one done in C++ and only
one in Ruby?
I think PyPy achieved true threading.
Anyway, with dual cores everywhere, Toshiba using Ruby over the Cell
processor, etc. Multicore-systems will not go away and the pressure
for Ruby to fully use will only increase.