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