Messages in this thread | | | Date | Mon, 27 Jan 2003 16:27:17 -0500 | From | "Bill Rugolsky Jr." <> | Subject | bug in select() (was Re: {sys_,/dev/}epoll waiting timeout) |
| |
On Thu, Jan 23, 2003 at 10:18:58PM +0000, Jamie Lokier wrote: > If, as someone said, the appropriate unix specification says that > "wait for 10ms" means to wait for _at minimum_ 10ms, then you do need > the +1. > > (Davide), IMHO epoll should decide whether it means "at minimum" (in > which case the +1 is a requirement), or it means "at maximum" (in > which case rounding up is wrong). > > The current method of rounding up and then effectively down means that > you get an unpredictable mixture of both.
Quite independent of this discussion, my boss came across this today while looking at some strace output:
gettimeofday({1043689947, 402580}, NULL) = 0 select(4, [0], [], [], {1, 999658}) = 0 (Timeout) gettimeofday({1043689949, 401857}, NULL) = 0 gettimeofday({1043689949, 401939}, NULL) = 0 select(4, [0], [], [], {0, 299}) = 0 (Timeout) gettimeofday({1043689949, 403577}, NULL) = 0
Note that 1043689949.401857 - 1043689947.402580 = 1.999277.
The Single Unix Specification (v2 and v3), says of select():
Implementations may also place limitations on the granularity of timeout intervals. If the requested timeout interval requires a finer granularity than the implementation supports, the actual timeout interval shall be rounded up to the next supported value.
That seems to indicate that a fix is required.
Regards,
Bill Rugolsky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |