Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
