> * 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
