On Tue, Jul 3, 2012 at 2:49 AM, Henrik Hallberg <henrik@k2h.se> wrote:
On Tue, Jul 03, 2012 at 01:08:34AM +0200, Jouke Witteveen wrote:
On Mon, Jul 2, 2012 at 11:07 PM, Henrik Hallberg <henrik@k2h.se> wrote:
--- src/globals | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/globals b/src/globals index 436334a..62cce3e 100644 --- a/src/globals +++ b/src/globals @@ -100,10 +100,11 @@ function checkyesno() { # $2...: condition command function timeout_wait() { local timeout="$1" + (( timeout *= 10 )) shift while ! eval "$*"; do (( timeout-- > 0 )) || return 1 - sleep 1 + sleep 0.1 done return 0 } -- 1.7.11.1
I don't think this is such a good idea. This saves less than .45 seconds on average per timeout_wait (old expected waste: .5s, new expected waste: .05s, added polling overhead).
If you assume uniform distribution, yes. However, this is not the case. For the cases which I fixed in patch 4, the first eval (no sleep at all) was sufficient. (Then, of course, the sleep time does not matter). If not, the second always was.
If you want to do it > this way, you should probably decouple (( timeout-- > 0 )) into (( timeout -= .1 )) and (( timeout > 0 )).
I could have sworn that I tested floating point calculations in bash, failed, and found texts claiming that it was not possible without e.g. `bc`. TIL.
Shame on me, you're right of course :-P.
Why would we try to make a bash script super fast?
Why keep unnescessary waiting times in? I'm happier to boot and have my net connected by the time my shell is. than waiting a little longer. With this and DHCP_OPTIONS='--noarp', it takes four seconds instead of twelve.
Well, they're not entirely unnecessary. Because it's a rather harmless, small patch I threw it in, but I hereby declare that I oppose the next suggestion to upgrade to 1/100th second polling ;-).