Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> Still, one could ask why we are expending extra cycles to make the
> >> timeout more accurate. Who the heck needs an accurate timeout on
> >> connect? Can you really give a use-case where the user won't have
> >> picked a number out of the air anyway?
>
> > I think we do need to properly compute the timeout on an EINTR of
> > select() because if we don't, a 30 second timeout could become 90
> > seconds if select() is interrupted. The other time() calls are needed,
> > one above the loop, and one inside the loop.
>
> AFAICS we need one time() call at the start, and then one inside the
> select loop. I haven't looked at your recent patches, but you said
> something about putting two calls in the loop; that seems like overkill.
Yes, one call at the start, and one in the loop. We need another in
pqWaitTimeout, but only if we hit EINTR. As the code stands now we do
time() unconditionally in pqWaitTimeout too because we only have to pass
in the funish time. If we want to pass in both finish and duration (for
use as select() timeout param), then we can eliminate the time() call in
there for the non-EINTR case. Is it worth the added code complexity?
That is what I am not sure about.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073