From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Use nanosleep(2) in pg_usleep, if available? |
Date: | 2019-03-12 00:03:40 |
Message-ID: | 4902.1552349020@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
In the thread about vacuum_cost_delay vs vacuum_cost_limit,
I wondered whether nanosleep(2) would provide any better
timing resolution than select(2). Some experimentation
suggests that it doesn't, but nonetheless I see a good reason
why we should consider making pg_usleep use nanosleep() if
possible: it's got much better-defined semantics for what
happens if a signal arrives. The comments for pg_usleep
lay out the problems with relying on select():
* 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.
While the WaitLatch alternative avoids the problem, I doubt
we're ever going to remove pg_usleep entirely, so it'd be
good if it had fewer sharp edges. nanosleep() has the
same behavior as Windows, ie, the sleep is guaranteed to be
terminated by a signal. So if we used nanosleep() where available
we'd have that behavior on just about every interesting platform.
nanosleep() does exist pretty far back: it's in SUSv2, though
that version of the standard allows it to fail with ENOSYS.
Not sure if we'd need to teach configure to check for that
possibility.
Thoughts?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Chapman Flack | 2019-03-12 00:07:48 | Re: Suggestions on message transfer among backends |
Previous Message | Euler Taveira | 2019-03-11 23:53:28 | Re: Suggestions on message transfer among backends |