In the thread about vacuum_cost_delay vs vacuum_cost_limit,
I wondered whether nanosleep(2) would provide any better
timing resolution than select(2). Some experimentation
suggests that it doesn't, but nonetheless I see a good reason
why we should consider making pg_usleep use nanosleep() if
possible: it's got much better-defined semantics for what
happens if a signal arrives. The comments for pg_usleep
lay out the problems with relying on select():
* CAUTION: the behavior when a signal arrives during the sleep is platform
* dependent. On most Unix-ish platforms, a signal does not terminate the
* sleep; but on some, it will (the Windows implementation also allows signals
* to terminate pg_usleep). And there are platforms where not only does a
* signal not terminate the sleep, but it actually resets the timeout counter
* so that the sleep effectively starts over! It is therefore rather hazardous
* to use this for long sleeps; a continuing stream of signal events could
* prevent the sleep from ever terminating. Better practice for long sleeps
* is to use WaitLatch() with a timeout.
While the WaitLatch alternative avoids the problem, I doubt
we're ever going to remove pg_usleep entirely, so it'd be
good if it had fewer sharp edges. nanosleep() has the
same behavior as Windows, ie, the sleep is guaranteed to be
terminated by a signal. So if we used nanosleep() where available
we'd have that behavior on just about every interesting platform.
nanosleep() does exist pretty far back: it's in SUSv2, though
that version of the standard allows it to fail with ENOSYS.
Not sure if we'd need to teach configure to check for that
possibility.
Thoughts?
regards, tom lane
