4 ms·

I thought that Linux behaved the same, but I'm not finding any proof in `man 2 nanosleep`...

• eqvinox 2y ago
  You can't find that proof because Linux does the opposite. Unless your task is SCHED_REALTIME, all timers have a little bit of slack at the end that allows the kernel to group wakeup events. You can configure this (for non-RT tasks) with prctl(PR_SET_TIMERSLACK). https://lxr.linux.no/#linux+v6.7.1/kernel/time/hrtimer.c#L2094 https://lxr.linux.no/#linux+v6.7.1/kernel/time/hrtimer.c#L20... https://www.man7.org/linux/man-pages/man2/PR_SET_TIMERSLACK.2const.html https://www.man7.org/linux/man-pages/man2/PR_SET_TIMERSLACK....
  • orbisvicis 2y ago
    Sorry! I was looking for documentation that on Linux sleep(0) yields.
    • eqvinox 2y ago
      There is no code in nanosleep that converts it into a yield, and in fact a nanosleep(0) is a nanosleep(50µs) with the default timer slack value. If you want to yield, call sched_yield() …
      • orbisvicis 2y ago
        I looked into this a bit further and it seems to be a range from [0,50]. [1] explains that if there is a pre-existing timer interrupt at 0, then the queue will be resumed at 0. But yes - given no other timers it will resume at 50. 1. https://people.kernel.org/joelfernandes/on-workings-of-hrtimers-slack-time-functionality https://people.kernel.org/joelfernandes/on-workings-of-hrtim...
• gpderetta 2y ago
  It used to be the case that glibc implemented nanosleep for small values below the scheduling quantum with a spin loop. It was explicitly documented to do so. This was changed sometimes in the last 20 years, probably with battery powered devices becoming more prevalent and CPUs implementing more advanced sleep states.