Commit 8c1a71d3 authored by Tom Lane's avatar Tom Lane

Add a comment warning against use of pg_usleep() for long sleeps.

Follow-up to commit 873ab972, in which
I noted that WaitLatch was a better solution in the commit log message,
but neglected to add any documentation in the code.
parent 1f09121b
...@@ -29,6 +29,16 @@ ...@@ -29,6 +29,16 @@
* the requested delay to be rounded up to the next resolution boundary. * the requested delay to be rounded up to the next resolution boundary.
* *
* On machines where "long" is 32 bits, the maximum delay is ~2000 seconds. * On machines where "long" is 32 bits, the maximum delay is ~2000 seconds.
*
* 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.
*/ */
void void
pg_usleep(long microsec) pg_usleep(long microsec)
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment