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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Use nanosleep(2) in pg_usleep, if available?
Дата
Msg-id 9173.1552410822@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Use nanosleep(2) in pg_usleep, if available?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Use nanosleep(2) in pg_usleep, if available?
Re: Use nanosleep(2) in pg_usleep, if available?
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Mar 11, 2019 at 8:03 PM Tom Lane <tgl@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?

(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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Timeout parameters
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: WIP: BRIN multi-range indexes