[Top][All Lists]

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

Re: [platform-testers] new snapshot available: grep-3.4-almost.19-ff30

From: Paul Eggert
Subject: Re: [platform-testers] new snapshot available: grep-3.4-almost.19-ff30
Date: Tue, 22 Sep 2020 14:12:42 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 9/22/20 12:39 PM, Jim Meyering wrote:

Unfortunately, that test: (requiring 124 exit from `timeout 0.01 sleep
0.02`) is racy. Sometimes, e.g., when run on a heavily-loaded system,
even gnu timeout may exit 0.

I figured that was OK, and even preferable to what grep had. My idea was that on a heavily-loaded system, or a system where 'timeout' and/or 'sleep' is busted for some other reason (macOS?), grep tests that involve timeouts are unreliable and generate more false alarms than they're worth, so let's skip 'em.

This is a judgment call of course. Others might prefer more test failures even if they're a lot of noise.

Clearly, sleeping multiple seconds at the start of each test is not
the right solution.

Yes, that's why I went with "timeout 0.01".

I considered "timeout 0.001" too. On the Ubuntu 18.04.5 desktop I'm typing this on, this command:

  for i in $(seq 1000); do
    timeout 0.001 sleep 0.002
    test $status -eq 124 || echo status=$?

succeeds without outputting anything, which is a good sign. The command takes 2.453 s real time. Multiplying the times by 10 raises the real time to 11.44 s. So we're starting to see diminishing returns by going from 0.01 to 0.001.

This may have exposed a bug in coreutils' timeout on that system.

I suppose we should add a test to coreutils for this - that's the right place to test 'timeout', anyway.

reply via email to

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