This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

increasing default timeout significantly

is there a compelling reason to keep the default timeout so low ?
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

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.

--- a/test-skeleton.c
+++ b/test-skeleton.c
@@ -46,8 +46,9 @@
 #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
 #define OPT_DIRECT 1000

Attachment: signature.asc
Description: Digital signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]