From: Eric Hodel Date: 2007-11-16T07:29:00+09:00 Subject: Re: state of threads in 1.9 On Nov 15, 2007, at 06:04 , Jordi wrote: > On Nov 15, 2007 7:33 AM, Eric Hodel wrote: >> On Nov 14, 2007, at 11:18 , Bill Kelly wrote: >>> From: "Berger, Daniel" >>>> 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) If this is something you really want to have happen, the best way to make it reality is to start working on it yourself. Right now ruby is taking baby steps. >>> 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. We know this (it has been the plan since 2005), but we don't want to achieve true threading at the expense of performance. Right now there are more important things to work on. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars