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.