-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Jim Meyering on 11/24/2009 12:26 AM: >> How about this? Note there is a slight change in semantics to forking done >> by >> sort - I chose to cut the minimum wait time by a factor of 4, but increase >> the >> number of retries only by 2, for a net result that we give up twice as fast. > > Thanks. > > Actually, adding 2 (as you did for MAX_FORK_TRIES_COMPRESS) happens to be > perfect, since the retry delay is doubled at each iteration. Cutting the > initial delay by 4 is matched by doubling the delay two more times.
Oh right, I failed to account for exponential growth. > > However, for MAX_FORK_TRIES_DECOMPRESS, you should also merely add 2, > and not double it; there is a big difference between waiting 2^8 and 2^14 > seconds (~4 min and 4.5 hours) for the final iteration. As I imagine > being in the unusual situation where I'd see fork failure, I think when > the delay is larger than a second or two, sort should announce on stderr > what it is doing. Otherwise, the poor user will think sort has simply hung. > Even then, a delay of four minutes seems excessive, so maybe add only 1 or > even 0. I went with 4 and 9 (+2 and +1). > > Please update the log not to say "double", too: > > (MAX_FORK_TRIES_COMPRESS, MAX_FORK_TRIES_DECOMPRESS): Add 2, > to counteract the division by 4 in the length of the initial delay. > > Thanks for the cfg.mk addition. Committed, with your improvements. - -- Don't work too hard, make some time for fun as well! Eric Blake [email protected] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksL4McACgkQ84KuGfSFAYD2LwCgx8AnpXEH4E3Ae5estFS1kN82 ZeYAoMk1sk/ObzycIM5UbwbBmFL78v5y =qvhT -----END PGP SIGNATURE-----
