From: Gary Wright <gwtmp01@...>
Date: 2007-10-04T03:06:03+09:00
Subject: Re: Recent Criticism about Ruby (Scalability, etc.)


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).

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.

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.