From: Walton Hoops <walton@...>
Date: 2010-02-22T02:05:39+09:00
Subject: Re: Threads vs Processes

On 2/21/2010 9:00 AM, Tim Ferrell wrote:
> Robert Klemme wrote:
>
>    
>> Processes are fairly independent.  Threads share the same memory space
>> and if the process exits they are all gone.  In Ruby 1.8 there was only
>> one OS level thread that did the work for all Ruby threads so you could
>> not make good use of multiple cores that way.  OTOH, if your threads
>> just control external programs that you execute (e.g. via "system" or
>> "IO.popen") then the single thread might be sufficient.  In 1.9 things
>> have been improved but still there are some limitations to the
>> concurrency of multiple threads.  Using JRuby with real threads is also
>> an option.
>>      
> Thanks - that clears things up a good bit for me :-)
>
>    
>> Performance wise and from a robustness point of view multiple processes
>> are probably better.  AFAIK the windows version of Ruby does not have
>> support for "fork" (unless you are using cygwin) so there you might
>> rather want to use threads.
>>      
> On Windows fork() is supported using the win32-process gem, although I
> have not looked at the code to see what mechanism is actually driving
> the implementation...
>
>    
>> Using processes is fairly easy - you can try it out with something like
>> this:
>>
>>      
> Thanks for the example code ... and if I am following all of this
> correctly, there really isn't a way to "monitor" the status of a
> Process, right? The only option is to "wait()" for it and then grab the
> exit status... correct?
>
> Thanks again,
> Tim
>    
Correct.

One thing I thought I'd add: you might give DRb a look-see.  It provides 
a nice easy way
to perform inter-process communication in Ruby. I think it would be 
fairly easy to implement a
worker pool with processes instead of threads using DRb.