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

[Paul Eggert]

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
    status=$?
    test $status -eq 124 || echo status=$?
  done

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.