Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit8c1a71d

Browse files
committed
Add a comment warning against use of pg_usleep() for long sleeps.
Follow-up to commit873ab97, in whichI noted that WaitLatch was a better solution in the commit log message,but neglected to add any documentation in the code.
1 parent1f09121 commit8c1a71d

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(longmicrosec)

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp