Re: Use nanosleep(2) in pg_usleep, if available? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Use nanosleep(2) in pg_usleep, if available?
Date
Msg-id 9875.1552412181@sss.pgh.pa.us
Whole thread Raw
In response to Re: Use nanosleep(2) in pg_usleep, if available?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Mar 12, 2019 at 1:13 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> (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.)

> Yeah, that's a fair question.  My motivation for asking was that I
> sometimes try to insert sleeps when debugging things, and they don't
> actually sleep, because they get interrupted.  That's not dispositive,
> though.

There never has been a guarantee that we won't sleep for *more*
than the requested time; the kernel might not give us back the
CPU right away.  But re-sleeping would at least ensure that
we won't sleep for *less* than the requested time.  So my opinion
after five minutes' thought is that re-sleeping is better, because
it gives you at least some kind of promise related to the function's
nominal semantics.

It still depends on whether we can make Windows do it, though.
I suppose a brute-force way would be like what WaitLatch does:
do our own timekeeping using instr_time.h.  (That'd work for
select as well, I guess.)

            regards, tom lane


pgsql-hackers by date:

Previous
From: Neel Patel
Date:
Subject: Getting ERROR: bogus varno: 2
Next
From: Tom Lane
Date:
Subject: Re: Getting ERROR: bogus varno: 2