Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 8c1a71d

Browse files
committed
Add a comment warning against use of pg_usleep() for long sleeps.
Follow-up to commit 873ab97, in which I noted that WaitLatch was a better solution in the commit log message, but neglected to add any documentation in the code.
1 parent 1f09121 commit 8c1a71d

File tree

1 file changed

+10
-0
lines changed

1 file changed

+10
-0
lines changed

src/port/pgsleep.c

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -29,6 +29,16 @@
2929
* the requested delay to be rounded up to the next resolution boundary.
3030
*
3131
* On machines where "long" is 32 bits, the maximum delay is ~2000 seconds.
32+
*
33+
* CAUTION: the behavior when a signal arrives during the sleep is platform
34+
* dependent. On most Unix-ish platforms, a signal does not terminate the
35+
* sleep; but on some, it will (the Windows implementation also allows signals
36+
* to terminate pg_usleep). And there are platforms where not only does a
37+
* signal not terminate the sleep, but it actually resets the timeout counter
38+
* so that the sleep effectively starts over! It is therefore rather hazardous
39+
* to use this for long sleeps; a continuing stream of signal events could
40+
* prevent the sleep from ever terminating. Better practice for long sleeps
41+
* is to use WaitLatch() with a timeout.
3242
*/
3343
void
3444
pg_usleep(long microsec)

0 commit comments

Comments
 (0)