Denys Vlasenko wrote: > I think scheduler is at play here. > Imagine a low-end system (say ~100MHz cpu) with rather poor capabilities > wrt measuring time. No microsecond clock, just timer interrupts. > > If one runs Linux on such a system with HZ=100, poll() with timeout of 10ms > is basically a "one timer tick timeout". I don't know how precise it can be. > To be exact, can kernel ensure that it won't be significantly _smaller_ > than 10ms? What if poll() was called soon before our 10ms timeslice > was going to expire anyway? When the timeout will expire? Next timeslice? > Then it can be smaller than 10ms. Two timeslices from now? > This means almost always poll(10) will do ~20ms waits. > > Therefore, I think poll(10ms) might be somewhat iffy wrt timeout duration. > If we want to err on the safe side, we'd better use at the very least 20ms.
While the man-pages for poll and select don't specify what happens for short timeouts, the man-page for nanosleep says: > nanosleep delays the execution of the program for *at least* the time specified. Everything else wouldn't make sense. Imagine a high-end system with HT=1000 and poll with timeout of 1ms. Now poll() happens to be called just 1µs before the end of the timeslice. If the kernel wouldn't wait for *at least* the specified time, the behavior would be undefined and such a timeout would be useless. Regards Ralf Friedl _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
