Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Denis A Ustimenko <denis(at)oldham(dot)ru>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Date: 2002-10-16 14:56:31
Message-ID: 200210161456.g9GEuWm24792@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Yes, the new code has _three_ time() calls, rather than the old code
> > that I think only had two. I was going to mention it but I figured
> > time() was a pretty light system call, sort of like getpid().
> > I needed the additional time() calls so the computation of remaining
> > time was more accurate, i.e. we are not resetting the timer on a
> > select() EINTR anymore.
>
> As long as the time() calls aren't invoked in the default no-timeout
> case, I doubt that the small additional slowdown matters too much.
> 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.

The only thing I can do is to pass in the end time _and_ the duration to
pqWaitTimeout and do the time() recomputation only on EINTR. This would
compute duration in the loop where I call time() and therefore elminate
a time() call in the normal, non-EINTR case. Of course, it makes the
code more complicated, and that is why I avoided it.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-10-16 15:01:33 Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Previous Message Tycho Fruru 2002-10-16 14:50:35 Re: Postgresql and multithreading