On Tue, Mar 12, 2019 at 6:13 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Mon, Mar 11, 2019 at 8:03 PM Tom Lane <t...@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. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
