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: Denis A Ustimenko <denis(at)oldham(dot)ru>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Date: 2002-10-15 03:38:55
Message-ID: 200210150338.g9F3ctl16626@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Denis A Ustimenko wrote:
> Tom, excuse me, I forget to copy previous posting to pgsql-hackers(at)postgresql(dot)org(dot)
>
> On Mon, Oct 14, 2002 at 09:53:27AM -0400, Tom Lane wrote:
> > Denis A Ustimenko <denis(at)oldham(dot)ru> writes:
> > > On Sun, Oct 13, 2002 at 10:59:40PM -0700, Joe Conway wrote:
> > >> Well, if we were specifying the timeout in microseconds instead of seconds,
> > >> it would make sense to have better resolution. But when you can only
> > >> specify the timeout in seconds, the internal time comparison doesn't need
> > >> to be any more accurate than seconds (IMHO anyway).
> >
> > > Actually we have the state machine in connectDBComplete() and the timeout is
> > > set for machine as the whole. Therefore if 1 second timeout is seted for the
> > > connectDBComplete() the timeout of particualr iteration of loop can be less
> > > then 1 second.
> >
> > However, the code's been restructured so that we don't need to keep
> > track of the exact time spent in any one iteration. The error is only
> > on the overall delay. I agree with Joe that it's not worth the effort
> > needed (in the Win32 case) to make the timeout accurate to < 1 sec.
> >
>
> Beware of almost 1 second posiible error. For example: connect_timeout == 1,
> we start at 0.999999 then finish_time == 1. If CPU is quite busy we will
> do only one iteration. I don't know is it enough to make connection?
> True timeout in this case == 0.000001

Good question. What is going to happen is that select() is going to be
passed tv_sec = 1, and it is going to sleep for one second. Now, if
select is interrupted, another time() call is going to be made. If the
second ticked just before we run time(), we are going to think one
second has elapsed and return, so in the non-interrupt case, we are
going to be fine, but with select() interrupted, we are going to have
this problem. Now, if we used gettimeofday(), we would be fine, but we
don't have that on Win32 and the ported version of that looks pretty
complicated. Maybe we will go with what we have and see if anyone
complains.

One idea I am looking at is to pass a time_t into pqWaitTimeout, and do
that clock checking in there, and maybe I can do a gettimeofday() for
non-Win32 and a time() on Win32.

--
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 Jeff Davis 2002-10-15 03:47:05 Re: [GENERAL] Postgres-based system to run .org registry?
Previous Message Denis A Ustimenko 2002-10-15 03:30:01 Re: droped out precise time calculations in src/interfaces/libpq/fe-connect.c