From: Thomas Munro Date: Wed, 15 Mar 2023 04:38:11 +0000 (+1300) Subject: Use nanosleep() to implement pg_usleep(). X-Git-Url: http://git.postgresql.org/gitweb/-?a=commitdiff_plain;h=a948e49e2ef11815be0b211723bfc5b53b7f75a8;p=users%2Frhaas%2Fpostgres.git Use nanosleep() to implement pg_usleep(). 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 Suggested-by: Paul Guo Suggested-by: Tom Lane 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 --- diff --git a/src/port/pgsleep.c b/src/port/pgsleep.c index b34efeae8c..a1bcd78e4b 100644 --- a/src/port/pgsleep.c +++ b/src/port/pgsleep.c @@ -12,9 +12,7 @@ */ #include "c.h" -#include -#include -#include +#include /* * 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