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

Re: HAVE_GMTIME_R?



I'm seeing a lot of warnings about lutil_tm declaration inside function params when compiling a fresh HEAD now. Seems to me there's something missing from these recent commits.

masarati@aero.polimi.it wrote:

That would mean moving lutil_gettime() (and its caller lutil_csnstr()?)
to libldap, so libldap_r can use the mutex.

Well, I was about to discuss this.  In fact, there's a few comments in the
code that seem to indicate the gmtime_mutex is used for other purposes
than calling gmtime(3) safely.  I mean: I plan to use gmtime(3) this way,

#ifdef USE_GMTIME_R
#define ldap_pvt_gmtime(t,tm) gmtime_r((t), (tm))
#else
struct tm *ldap_pvt_gmtime(time_t *t, struct tm *tm)
{
     struct tm *tm_ptr;
#ifdef LDAP_R_COMPILE
     ldap_pvt_thread_mutex_lock(&gmtime_mutex );
#endif
     tm_ptr = gmtime( t );
     *tm = *tm_ptr;
#ifdef LDAP_R_COMPILE
     ldap_pvt_thread_mutex_unlock(&gmtime_mutex );
#endif
     return tm;
}

This means that the result of calling ldap_pvt_gmtime() will always be
safe.  However, somewhere in the code there was things like

     ldap_pvt_thread_mutex_lock(&gmtime_mutex );
     // do something that implies calling gmtime()
     ldap_pvt_thread_mutex_unlock(&gmtime_mutex );

I guess the only reason was to avoid copying the contents of the structure
returned by gmtime(3).  I need to check whether my assumption is correct
or not.  Significant cases include calling lutil_csnstr().


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