1berry/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Use nanosleep() to implement pg_usleep().

Browse Source 
The previous coding based on select() had commentary about historical
portability concerns.  Use POSIX nanosleep() instead.

This has independently been suggested a couple of times before, but
never managed to stick.  Since recent and proposed work removes other
uses of select(), and associated code and comments relating to its
non-portable interaction with signals, it seems like a good time to tidy
up this case, too.

Also modernize the explanation of why WaitLatch() is a better way to
wait.

Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>
Suggested-by: Paul Guo <paulguo@gmail.com>
Suggested-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CAAKRu_b-q0hXCBUCAATh0Z4Zi6UkiC0k2DFgoD3nC-r3SkR3tg%40mail.gmail.com
Discussion: https://postgr.es/m/CABQrizfxpBLZT5mZeE0js5oCh1tqEWvcGF3vMRCv5P-RwUY5dQ@mail.gmail.com
Discussion: https://postgr.es/m/4902.1552349020@sss.pgh.pa.us
This commit is contained in:
Thomas Munro 2023-03-15 17:38:11 +13:00
parent e4da2a44c1
commit a948e49e2e
1 changed files with 10 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
src/port/pgsleep.c
View File

@ -12,9 +12,7 @@
*/
#include "c.h"
#include <unistd.h>
#include <sys/select.h>
#include <sys/time.h>
#include <time.h>
/*
* In a Windows backend, we don't use this implementation, but rather
@ -32,15 +30,12 @@
*
* 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.
* CAUTION: It's not a good idea to use long sleeps in the backend. They will
* silently return early if a signal is caught, but that doesn't include
* latches being set on most OSes, and even signal handlers that set MyLatch
* might happen to run before the sleep begins, allowing the full delay.
* Better practice is to use WaitLatch() with a timeout, so that backends
* respond to latches and signals promptly.
*/
void
pg_usleep(long microsec)
@ -48,11 +43,11 @@ pg_usleep(long microsec)
if (microsec > 0)
{
#ifndef WIN32
struct timeval delay;
struct timespec delay;
delay.tv_sec = microsec / 1000000L;
delay.tv_usec = microsec % 1000000L;
(void) select(0, NULL, NULL, NULL, &delay);
delay.tv_nsec = (microsec % 1000000L) * 1000;
(void) nanosleep(&delay, NULL);
#else
SleepEx((microsec < 500 ? 1 : (microsec + 500) / 1000), FALSE);
#endif