Messages in this thread | | | Date | Sat, 21 Feb 2004 16:18:06 +0000 | From | Jamie Lokier <> | Subject | Re: [PATCH][4/4] poll()/select() timeout behavior |
| |
Andrew Morton wrote: > > Unfortunately, fixing the fencepost error places a hard lower limit of > > 1/HZ on the time slept, and increases the average minimum sleep time > > threefold, from 1/(2*HZ) jiffy to 3/(2*HZ). > > I'm inclined to live with the current behaviour rather than > risk breaking existing apps.
select's behaviour is fun when trying to do smooth game animation on X... Humans are pretty good at noticing jitter in the animation of a moving object. Years ago, I ended up writing an estimator which deduced the granularity and rounding of select(), so that I could then _reduce_ the timeout given to select() followed by a busy wait up to the desired time. That was needed for SunOS. Nowadays with 1kHz jiffies it's not a problem, but not all systems have that.
So, I agree, the change might break current apps.
If the current behaviour is retained, shouldn't select(), poll() and epoll() at least agree on the same rounding direction? poll/epoll should be suitable as replacements for select, but I don't think they are timing-wise.
(Btw, Bill, did you take a look at epoll too?)
-- Jamie - 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/
| |