mirror of
https://github.com/postgres/postgres.git
synced 2025-08-08 06:02:22 +03:00
Add a comment warning against use of pg_usleep() for long sleeps.
Follow-up to commit 873ab97219
, in which
I noted that WaitLatch was a better solution in the commit log message,
but neglected to add any documentation in the code.
This commit is contained in:
@@ -29,6 +29,16 @@
|
||||
* 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.
|
||||
*
|
||||
* 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
|
||||
pg_usleep(long microsec)
|
||||
|
Reference in New Issue
Block a user