> * NOTE: although the delay is specified in microseconds, the effective > - * resolution is only 1/HZ, or 10 milliseconds, on most Unixen. Expect > - * the requested delay to be rounded up to the next resolution boundary. > + * resolution is only 1/HZ on systems that use periodic kernel ticks to wake > + * up. This may cause sleeps to be rounded up by 1-20 milliseconds on older > + * Unixen and Windows.
nitpick: Could the 1/HZ versus 20 milliseconds discrepancy cause confusion? Otherwise, I think this is the right idea. > + * CAUTION: if interrupted by a signal, this function will return, but its > + * interface doesn't report that. It's not a good idea to use this > + * for long sleeps in the backend, because backends are expected to respond > to > + * interrupts promptly. Better practice for long sleeps is to use > WaitLatch() > + * with a timeout. I'm not sure this argument follows. If pg_usleep() returns if interrupted, then why are we concerned about delayed responses to interrupts? > - delay.tv_usec = microsec % 1000000L; > - (void) select(0, NULL, NULL, NULL, &delay); > + delay.tv_nsec = (microsec % 1000000L) * 1000; > + (void) nanosleep(&delay, NULL); Using nanosleep() seems reasonable to me. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
