Re: Improve the granularity of PQsocketPoll's timeout parameter?

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> I agree it makes things easier for a caller following that pattern,
> because it doesn't need to recalculate the timeout each time through
> the loop.

> But:

> 1. If your clock goes backwards, you can end up waiting for an
> arbitrarily long time. To prevent that you need to do some
> recalculation each time through the loop anyway.

[ shrug... ] The only reason this has come up is that f5e4dedfa
exposed what was previously just libpq-private code. Given that
that code has operated in this way for a couple of decades with
approximately zero trouble reports, I'm not very interested in
re-litigating its theory of operation. The more so if you don't
have a concrete better alternative to propose.

> 2. Inventing a new absolute time type just for this single purpose
> seems strange to me. Would it be useful in other places? Are we going
> to define what kinds of operations/transformations are supported?

I'm not that thrilled with inventing a new time type just for this,
either. However, time_t is not very fit for purpose, so do you
have a different suggestion?

We could make it a bit nicer-looking by wrapping "long long int"
in a typedef, but that's only cosmetic.

> 3. I can't recall another API that uses absolute time for a timeout;
> are you aware of a precedent?

The other thing that I've seen done is for select(2) to treat the
timeout as an in/out parameter, decrementing it by the amount of
time slept. I hope you'll agree that that's a monstrous kluge.

regards, tom lane