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

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

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?

(I'm not sure what I think about which behavior is really more
desirable. We can debate that if there's actually a plausible
choice to be made, which seems to depend on Windows.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2019-03-12 17:14:53 Re: WIP: BRIN multi-range indexes
Previous Message Robert Haas 2019-03-12 17:05:20 Re: Timeout parameters