[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sort link failure due to sleep

From: Eric Blake
Subject: Re: sort link failure due to sleep
Date: Tue, 24 Nov 2009 06:33:59 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090812 Thunderbird/ Mnenhy/

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]