Re: Use nanosleep(2) in pg_usleep, if available?

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Use nanosleep(2) in pg_usleep, if available?
Date: 2019-03-13 12:02:04
Message-ID: CABUevEx1=5kh8cC_zhhpaPJDTx9c4RPzHOW49gLmRbnxnKSzMQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 12, 2019 at 6:13 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Mon, Mar 11, 2019 at 8:03 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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/>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-03-13 12:03:46 Fix handling of unlogged tables in FOR ALL TABLES publications
Previous Message Michael Paquier 2019-03-13 11:56:33 Re: Offline enabling/disabling of data checksums