summary refs log tree commit diff
path: root/test-skeleton.c
diff options
context:
space:
mode:
authorMike Frysinger <vapier@gentoo.org>2016-01-19 09:18:00 -0500
committerMike Frysinger <vapier@gentoo.org>2016-02-19 13:48:56 -0500
commita28605b22946c708f0a5c4f06307e1a17650ced8 (patch)
tree801d493da1959b461fb1f2f644716dc020731400 /test-skeleton.c
parentb6ebba701c6d6ecc73881e551ea8d49f0e02c93a (diff)
downloadglibc-a28605b22946c708f0a5c4f06307e1a17650ced8.tar.gz
glibc-a28605b22946c708f0a5c4f06307e1a17650ced8.tar.xz
glibc-a28605b22946c708f0a5c4f06307e1a17650ced8.zip
test-skeleton: increase default TIMEOUT to 20 seconds
The vast majority of timeouts I've seen w/glibc tests are due to:
 - slow system (e.g. <1 GHz cpu)
 - loaded system (e.g. lots of parallelism)
Even then, I've seen timeouts on system I don't generally consider
slow, or even loaded, and considering TIMEOUT is set to <=10 in ~60
tests (and <=20 in ~75 tests), it seems I'm not alone.  I've just
gotten in the habit of doing `export TIMEOUTFACTOR=10` on all my
setups.

In the edge case where there is a bug in the test and the timeout is
hit, I think we all agree that's either a problem with the test or a
real bug in the library somewhere.  In either case, the incident rate
should be low, so catering to that seems like the wrong trade-off.

Other developers too usually set large timeout factors.  Increase the
default to 20 seconds to match reality.
Diffstat (limited to 'test-skeleton.c')
-rw-r--r--test-skeleton.c5
1 files changed, 3 insertions, 2 deletions
diff --git a/test-skeleton.c b/test-skeleton.c
index a2edf836b7..a2d90a298f 100644
--- a/test-skeleton.c
+++ b/test-skeleton.c
@@ -46,8 +46,9 @@
 #endif
 
 #ifndef TIMEOUT
-  /* Default timeout is two seconds.  */
-# define TIMEOUT 2
+  /* Default timeout is twenty seconds.  Tests should normally complete faster
+     than this, but if they don't, that's abnormal (a bug) anyways.  */
+# define TIMEOUT 20
 #endif
 
 #define OPT_DIRECT 1000