Re: HAVE_GMTIME_R?

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

> struct tm *ldap_pvt_gmtime(

                             const /* and LDAP_CONST in the .h file */

>                            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 );

      if (tm_ptr == NULL) tm = NULL; else

>     *tm = *tm_ptr;
> #ifdef LDAP_R_COMPILE
>     ldap_pvt_thread_mutex_unlock( &gmtime_mutex );
> #endif
>     return tm;
> }

>> But not exposing gmtime_mutex would break third-partly modules that
>> use gmtime()/localtime() correctly, which means protecting them with
>> gmtime_mutex.  We could however register gmtime_mutex in libldap,
>> similar to registering which memory functions to use.
> 
> Right.  But as far as I can tell, this is already the case of other
> mutex'es, including ldap_int_ctime_mutex, which is static, and other
> ldap_int_*_mutex'es, that are internal to libldap.

Still shouldn't break existing code which does work.  Not in a minor
release at least.

> I'd rather favor exposing an API that allows to lock/unlock (trylock?)
> hidden mutexes.  Although I fear this could open a can of worms.

Yes, it's a problem when several packages all want to "own" the mutex
protecting a function (or rather, protecting its static data).

The friendliest way to handle that is an API which (a) accepts that the
caller passes it the mutexes to set up (and maybe the mutex-lock
functions too), and (b) provides useful defaults so callers don't need
to do that.

-- 
Hallvard