Re: HAVE_GMTIME_R?

[masarati@aero.polimi.it]

> masarati@aero.polimi.it writes:
>> Other time-related, and significantly those using the
>> lutil_tm struct, remained in liblutil.  Probably ldap_pvt.h needs to
>> include lutil.h.  Suggestions?
>
> I fixed it.

Thanks

> The gcc warning explained clearly enough what was wrong.

I meant: in terms of opportunity.  You can fix it directly by declaring
the structure, or by anticipating the inclusion of lutil.h, since
ldap_pvt.h depends on it.

> I still disagree that moving gmtime_mutex out of slapd was the right
> thing to do in the middle of RE24 though.  Though i suppose we could
> '#define gmtime_mutex ldap_int_gmtime_mutex' so slapd at least remains
> source-code compatible.

Mmmmh, ldap_int_gmtime_mutex is (and should in the long term remain)
static.  I see your point in hiding a symbol within bugfix releases, but I
wonder how many applications cared about that in the first place, and how
many developers are aware of the issue.

In general, I realize the library design needs to take into account two
different issues related to re-entrancy:

1) the need for thread-safe behavior of libldap when usen in multithread
clients (libldap_r)

2) the need to cure potential flaws in non re-entrant libraries OpenLDAP's
depend on.

The two issues are orthogonal, in the sense that we can carefully design
libldap's thread-safety, and provide indications about how to design
thread-safe applications that use it.

As an entirely separate issue, we need to provide means to make
thread-safe the use of potentially unsafe functions that we need.  This is
a bit harder, because:

a) we may need to use potentially unsafe functions in pieces of code not
necessarily designed for thread-safety (e.g. liblutil in this case)

b) we may need to cooperate with other protections put in place by
applications.

In any case, protection needs mutexes, and if we own them, we need to
initialize them.

Usually, we put these things in libldap because it initializes itself
(perhaps in a clumsy manner, by requiring to call at least a routine
before threads are spawn), but this is good for case (1), libldap's
thread-safe behavior.  For case (2), curing re-entrance issues, I'm not
sure what we'd do.

p.