4 ms·
You shouldn't use time in this scenario at all, but wait on a condition. It's unreasonable to expect a non-realtime kernel to offer this precision with timers.
by eska 6y ago
You shouldn't use time in this scenario at all, but wait on a condition. It's unreasonable to expect a non-realtime kernel to offer this precision with timers. Doing serious audio work on non-realtime kernels, you have to expect such issues.
- gambiting 6y agoAgain, on windows using waits on kernel objects has the exact same result. A signaled object will only wake up the waiting thread at the timer interrupt, so it doesn't matter if you use sleep(1) and check if there is work to do, or if you use a kernel object and wait on it - the time spent sleeping will be exactly identical.
- vardump 6y agoWell, there's a fine line here. Correct me if I'm wrong, but if it's hardware based IRP completion (like DMA done, network card received a packet or whatever), your thread could wake up very soon after I/O completes, long before the next timer tick. But this is not something you can use for timing, unless of course your hardware is built to do so.
- Dylan16807 6y agoThe wait time will be the same but the amount of wasted CPU won't. It's not a lot but it adds up. If it's only on your servers then whatever, but if the code goes to clients then please wait on an event.