> I would think the following code would wait for 1 second each > itteration before printing hello, but it waits way too long. > Replacing the for loop body with a usleep(1000000) works > great... what am I missing here? Essentially, that usleep() isn't actually terribly accurate for short waits. First, you always give up the rest of your timeslice, which delays you a few milliseconds (more if there's contention for the processor). Second, kernel timers will always fire a short period after the actual specified time, which gives you a further small, roughly constant delay. Third, you aren't actually woken up immediately after the timer goes off; you simply become eligible for scheduling again.
This means that when you call usleep(x), you actually end up sleeping for x + n us, where n is a few thousand. If you call usleep(1000000), this will probably be less than one percent of the total time slept, so nobody really cares. If you call usleep(1000), it's likely to be several times the actual sleep time required, which you almost certainly do care about. If you really can't call usleep() or nanosleep() with a big number, the only option is probably to spin: the kernel can't cope with really fine-grained scheduling. If you're root, you can use a real time process, in which case the kernel will do the spinning for you for delays of less than 2ms. Depending on the exact delay being used and how you calibrate the busy wait, this may be slightly more accurate. Steven Smith, [EMAIL PROTECTED]
pgp00000.pgp
Description: PGP signature
