From: Chad Perrin Date: 2007-10-04T04:45:59+09:00 Subject: Re: Recent Criticism about Ruby (Scalability, etc.) On Thu, Oct 04, 2007 at 03:06:03AM +0900, Gary Wright wrote: > > On Oct 3, 2007, at 5:40 AM, Robert Klemme wrote: > >It definitively is. One aspect of Ruby that hinders scaling is the > >absence of native threads IMHO. On the other hand, mechanisms are > >provided for IPC (DRb for example) which are easy to use and thus > >may be counted as compensating at least partially for the lack of > >native threading. > > I admit to being puzzled by the general fascination > with threads (native or not) for solving scaling > problems. > > Good old processes have always seemed like a reasonable > way to partition problems and take advantage of > concurrency opportunities due to waiting on I/O > (single processor) or the parallel nature of a > CPU-bound calculation (multi-processor). There's entirely too much focus on threads these days. In many cases, separate processes are superior to multithreading concurrency. On the other hand, there are cases where multithreading concurrency is superior to multiprocessing concurrency. > > Processes also prevent the kind of problems associated > with concurrent access to shared memory that are > inherent in a multi-thread/single-process model. > A multi-process solution can more easily be > retargeted to a multi-machine solution across a network > than can a multi-thread solution. On the other hand, sometimes it's nice to keep process overhead down. Most of the time, however, I think multithreaded concurrency is a case of premature optimization. > > I suspect that language and OS features have a great > affect on the concurrency model a programmer might > select or prefer. > > I'm not suggesting that processes are in all cases > preferred to threads just that I would tend to explore > a multi-process solution *first* before a multi-thread > solution. Same here. That's one of the reasons that, though I know a fair bit about multithreaded concurrency in theory, I've done very little with multithreaded development in practice. In fact, all I've found need to do with mutilthreaded dev so far is dealing with others' code, where the code was implemented using multithreaded concurrency before I ever laid eyes on it. -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] Ben Franklin: "As we enjoy great Advantages from the Inventions of others we should be glad of an Opportunity to serve others by any Invention of ours, and this we should do freely and generously."