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
-- 
Posted via http://www.ruby-forum.com/.