| Subject: | t/04standby.t may fail |
The test suite may fail, and the most frequent reason seems to be a failing t/04standby.t test: <http://analysis.cpantesters.org/reports_by_field?distv=IPC-ConcurrencyLimit-0.17;field=fail%3At%2F04standby.t>
One problem is the usage of ok() in the "We actually waited about 3s as expected" test. So one cannot see if the actual wait time is shorter or longer (possibly both may happen). Rewriting this test case to use two cmp_ok() calls would improve diagnostics:
diff --git a/t/04standby.t b/t/04standby.t
index ac9cf8f..8a03891 100644
--- a/t/04standby.t
+++ b/t/04standby.t
@@ -18,7 +18,7 @@ SKIP_MSG
}
}
-use Test::More tests => 6;
+use Test::More tests => 7;
# TMPDIR will hopefully put it in the logical equivalent of
# a /tmp. That is important because no sane admin will mount /tmp
@@ -91,7 +91,11 @@ SCOPE: {
my $idr = $limit->get_lock;
my $when2 = Time::HiRes::time;
ok( defined $idr, 'Got 2nd lock after infinite retry (.01 s interval)' );
- ok( ( $when2 - $when >= 3 && $when2 - $when <= 4 ),
+ my $waited = $when2 - $when;
+ cmp_ok( $waited, '>=', 3,
+ 'We actually waited about 3s as expected'
+ );
+ cmp_ok( $waited, '<=', 4,
'We actually waited about 3s as expected'
);
exit 0;
I suspect two possible reasons:
* a loaded system which is causing the child to take longer to get the lock, or the parent taking longer to release the lock
* for some reason and despite of the 0.1s sleep the child is faster in getting the lock than the parent
With the improved diagnostics one could probably tell which of the both reasons it is.