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

Em qua., 12 de jun. de 2024 às 14:53, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> escreveu:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > I agree this is not great. I guess I didn't think about it very hard
> > because, after all, we were just exposing an API that we'd already
> > been using internally. But I think it's reasonable to adjust the API
> > to allow for better resolution, as you propose. A second is a very
> > long amount of time, and it's entirely reasonable for someone to want
> > better granularity.
>
> Here's a v2 responding to some of the comments.
>
> * People pushed back against not using "int64", but the difficulty
> with that is that we'd have to #include c.h or at least pg_config.h
> in libpq-fe.h, and that would be a totally disastrous invasion of
> application namespace. However, I'd forgotten that libpq-fe.h
> does include postgres_ext.h, and there's just enough configure
> infrastructure behind that to allow defining pg_int64, which indeed
> libpq-fe.h is already relying on. So we can use that.
>
> * I decided to invent a typedef
>
> typedef pg_int64 PGusec_time_t;
>
Perhaps pg_timeusec?
I think it combines with PQgetCurrentTimeUSec

>
> instead of writing "pg_int64" explicitly everywhere. This is perhaps
> not as useful as it was when I was thinking the definition would be
> "long long int", but it still seems to add some readability. In my
> eyes anyway ... anyone think differently?
>
> * I also undid changes like s/end_time/end_time_us/. I'd done that
> mostly to ensure I looked at/fixed every reference to those variables,
> but on reflection I don't think it's doing anything for readability.
>
end_time seems much better to me.

>
> * I took Ranier's suggestion to make fast paths for end_time == 0.
> I'm not sure this will make any visible performance difference, but
> it's simple and shouldn't hurt. We do have some code paths that use
> that behavior.
>
Thanks.

>
> * Ranier also suggested using clock_gettime instead of gettimeofday,
> but I see no reason to do that. libpq already relies on gettimeofday,
> but not on clock_gettime, and anyway post-beta1 isn't a great time to
> start experimenting with portability-relevant changes.
>
I agree.
For v18, it would be a case of thinking about not using it anymore
gettimeofday, as it appears to be deprecated.

best regards,
Ranier Vilela