[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: ldap_result() and timeval



Well, yes I have looked at the source for this, but not having any socket
experience I thought time would be better served if I posted this to the
list.  Thanks for your reply. I do have an additional question though.

In my testing I'm doing an ldap_add() and an ldap_search().  After sending
each request I poll with ldap_result() - with a timeout of 200ms - before
moving on to the next request. I print a timestamp everytime ldap_result()
returns.  The results I saw prompted my initial question.

When polling for the result from ldap_add() I see the 200ms timeout
occurring, as expected.
When polling for the result from ldap_search(), however, I see an almost
immediate return (10ms at most wait) each time it polls.  My search should
return 3 entries.  "all" is set to return the entire chain of search
entries.  I wouldn't have expected ldap_result() to return until the entire
chain was ready or a timeout occurred.  But maybe it's returning after
single entries are found - could this be the case?  If this is the case,
what good is the "all" parameter?

Another interesting thing I found during testing is that if the timeval is
set as follows {tv_sec=0, tv_usec=999000} it takes 3 polling attempts to get
my result, but if it's set as {tv_sec=1, tv_usec=0} a result is obtained
from the first ldap_result().

Dave Nelson


-----Original Message-----
From: Howard Chu [mailto:hyc@highlandsun.com]
Sent: Wednesday, September 26, 2001 10:57 AM
To: David Nelson; openldap-software@OpenLDAP.org
Subject: RE: ldap_result() and timeval


> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of David Nelson

> Can someone confirm whether ldap_result() only uses the tv_sec member and
> not the tv_usec member while waiting for results.  My testing seems to
> indicate this.
>
> I'm using the 1.2.11 library.

Are you unable to access the library source code yourself, for some reason?

The answer is "maybe" - the entire struct timeval is used by select(), of
course.
However, if select() returns early due to a signal, the check for how much
time
remains only computes seconds, not microseconds. The code uses the time()
call to
record when it started waiting and when it stopped. It seems to me that no
one
has ever asked for greater precision before, but this could easily be fixed
by
using gettimeofday() instead of time(). Also, some systems (like Linux)
update
the timeval inside select() automatically, so that when select() returns,
the
timeval already indicates how much time is left, and no extra compensation
is
needed by the user-level code. One would have to write a test program for
configure
if they wanted this feature to be detected and used in the library.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc