On Thu, Jan 18, 2007 at 05:47:53PM -0800, Dan Hipschman wrote: > That's a thought, although libz only works with gzip (as you said), and > it will add more complexity (like my original patch using LZO and this > new one combined). I don't think we'll have 40 instances of gzip -d > running. We should only need at most one compression process, and > NMERGE (16) decompression processes running at one time. I think > retrying fork if it fails is a good idea, and I've already added that > since I read your mail.
Apologies, I spoke to soon. We shouldn't have 40 *running* processes, but we generate a lot of defunct ones. I'm working on cleaning them up sooner and then hopefully we can bound the number of child processes at NMERGE + 1. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
