Re: sort link failure due to sleep

[Eric Blake]

-----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             address@hidden
-----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-----