Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Mar 11, 2019 at 8:03 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 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.
> Is there any feasible way to go the other way, and make pg_usleep() > actually always sleep for the requested time, rather than terminating > early?
> (Probably not, but I'm just asking.)
Yes, nanosleep would support that; it returns the remaining time after an interrupt, so we could just loop till done. The select-based implementation would have a hard time supporting it, though, and I have no idea about Windows.
Now, this proposal is predicated on the idea that we won't need to care too much about the select case because few if any platforms would end up using it. So really the question boils down to whether we can provide the continue-to-wait behavior on Windows. Anyone?
pg_usleep() on Windows uses WaitForSingleObject with a timeout, which cannot do that.
It seems we could fairly easily reimplement nthat on top of a waitable timer (CreateWaitableTimer/SetWaitableTimer) which should handle this situation. As long as it's only in pg_usleep() we need to change things, the change should be trivial.