[lkml]   [2003]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectbug 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.


Bill Rugolsky
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:32    [W:0.060 / U:31.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site