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:36:21 |
Message-ID: | 9875.1552412181@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 Tue, Mar 12, 2019 at 1:13 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-03-12 17:43:07 | Re: Getting ERROR: bogus varno: 2 |
Previous Message | Neel Patel | 2019-03-12 17:34:17 | Getting ERROR: bogus varno: 2 |