Bug 20762 - epoll_wait(2): upper limit to timeout
epoll_wait(2): upper limit to timeout
Status: RESOLVED CODE_FIX
Product: Documentation
Classification: Unclassified
Component: man-pages
All Linux
: P1 normal
Assigned To: documentation_man-pages@kernel-bugs.osdl.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-19 08:17 UTC by Fredrik Arnerup
Modified: 2012-08-16 09:33 UTC (History)
1 user (show)

See Also:
Kernel Version: n/a
Tree: Mainline
Regression: No


Attachments

Description Fredrik Arnerup 2010-10-19 08:17:03 UTC
The timeout argument has an upper limit. Any values above that limit are treated the same as -1, i.e. to wait indefinitely. The limit is given by:

#define EP_MAX_MSTIMEO min(1000ULL * MAX_SCHEDULE_TIMEOUT / HZ, (LONG_MAX - 999ULL) / HZ)

That is, the limit depends on the size of a long and the timer frequency. Assuming the a long is never smaller than 32 bits and HZ never larger than 1000, the worst case is 35 minutes. I think this should be mentioned under "BUGS".

Although this is likely to be fixed in the future (http://lkml.org/lkml/2010/8/8/144), the problem exists in at least 2.6.14 - 2.6.35. I don't know if select(2) and poll(2) are affected.
Comment 1 Michael Kerrisk 2012-08-16 09:33:31 UTC
I aplied the following patch:

--- a/man2/epoll_wait.2
+++ b/man2/epoll_wait.2
@@ -198,6 +198,18 @@ If the new file descriptor becomes ready,
 it will cause the
 .BR epoll_wait ()
 call to unblock.
+.SH BUGS
+In kernels before 2.6.37, a
+.I timeout
+value larger than approximately
+.I LONG_MAX / HZ
+milliseconds is treated as \-1 (i.e., infinity).
+Thus, for example, on a system where the
+.I sizeof(long)
+is 4 and the kernel
+.I HZ
+value is 1000,
+this means that timeouts greater than 35.79 minutes are treated as infinity.
 .SH "SEE ALSO"
 .BR epoll_create (2),
 .BR epoll_ctl (2),

Note You need to log in before you can comment on or make changes to this bug.