blob: a1bcd78e4b2cf4bc18869c5933449009b986a371 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
|
/*-------------------------------------------------------------------------
*
* pgsleep.c
* Portable delay handling.
*
*
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
*
* src/port/pgsleep.c
*
*-------------------------------------------------------------------------
*/
#include "c.h"
#include <time.h>
/*
* In a Windows backend, we don't use this implementation, but rather
* the signal-aware version in src/backend/port/win32/signal.c.
*/
#if defined(FRONTEND) || !defined(WIN32)
/*
* pg_usleep --- delay the specified number of microseconds.
*
* NOTE: Although the delay is specified in microseconds, older Unixen and
* Windows use periodic kernel ticks to wake up, which might increase the delay
* time significantly. We've observed delay increases as large as 20
* milliseconds on supported platforms.
*
* On machines where "long" is 32 bits, the maximum delay is ~2000 seconds.
*
* 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)
{
if (microsec > 0)
{
#ifndef WIN32
struct timespec delay;
delay.tv_sec = microsec / 1000000L;
delay.tv_nsec = (microsec % 1000000L) * 1000;
(void) nanosleep(&delay, NULL);
#else
SleepEx((microsec < 500 ? 1 : (microsec + 500) / 1000), FALSE);
#endif
}
}
#endif /* defined(FRONTEND) || !defined(WIN32) */
|
