Tim Ferrell wrote:
> 
> I have just switched back to Windows from the Mac/Linux world and my
> first non-web Ruby project is a program to manage a bunch of independent
> backup tasks ... the spec calls for allowing many tasks to be queued but
> to only allow a certain number to run at a time. I don't foresee the
> tasks needing to share any data with the parent process or each other
> but that might be an option to keep open...
> 
> My first thought is to do something along the lines of a thread pool and
> have each task as a thread... but then I thought of processes... I am
> admittedly a but fuzzy on the distinction between processes and threads
> in Ruby, especially on Windows... can someone shine some light on this
> for me?
> 
> Would one approach be easier to manage in this type of scenario? Are
> there any performance or portability issues I should be aware of?
> 
> Thanks much!
> Tim

You might take a look at SizedQueue. There's a good description of it in 
"The Ruby Programming Language" book. I used it as a work queue to 
request a boatload of remote files, from which a set of concurrent ftp 
connection threads pulled from to go get them.

I did notice, as forwarned, that the performance degraded after a while 
using the native ruby threads. If you're on Windows, though, you might 
give IronRuby a fling (or Jruby if it's installed). Those switch over to 
their framework's Thread classes, and worked very well.
-- 
Posted via http://www.ruby-forum.com/.