Use nanosleep() to implement pg_usleep().
authorThomas Munro <[email protected]>
Wed, 15 Mar 2023 04:38:11 +0000 (17:38 +1300)
committerThomas Munro <[email protected]>
Wed, 15 Mar 2023 04:57:12 +0000 (17:57 +1300)
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 <[email protected]>
Suggested-by: Paul Guo <[email protected]>
Suggested-by: Tom Lane <[email protected]>
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

src/port/pgsleep.c

index b34efeae8cd8c86a065917acdb1b432fb34fc45c..a1bcd78e4b2cf4bc18869c5933449009b986a371 100644 (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
  *
  * 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