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.