On 08/18/10 06:34 PM, Howard Chu wrote:
Kurt Zeilenga wrote:
Doug,
I note as a general rule, which I will follow in this case, I don't review
patches authors would like included in OpenLDAP Software until they have been formally submitted for review.
While the ITS submission provides for a review of what was done, my purpose in directing the conversation here is to discuss why. It's not clear to me that this old draft is still viable or desirable. As
Our prime motivation for integrating operation safe enhancements into OpenLDAP libldap is because we want to move off Mozilla libldap, and specifically off an old Solaris version of Mozilla libldap that has Solaris specific tweaks. Our end goal is to deliver generic OpenLDAP releases into Solaris, where the OpenLDAP libs/headers replace the existing core Solaris libldap libs/headers and we deliver the same level of compatibility as other distributions.
That said, Solaris naming services currently requires operation safe libldap operations as part of our LDAP naming support. We routinely multiplex requests from multiple threads over a single connection, or a small pool of connections using the known Mozilla libldap threading behaviors.
As I interpret draft-zeilenga-ldap-c-api-concurrency, the proposal introduces the ldap_dup and ldap_destroy APIs that both enable the operation safe enhancements we desire, and keep the existing OpenLDAP libldap behaviors 100% backwards compatible with previous releases.
So, I see the draft as a relevant and viable solution, that has already been implemented once AFAIK (Novell), and provides a valuable feature we (Solaris) strongly desire. I believe that other applications that desire to manage shared connections in a multi-threaded environment will also want to use this functionality.
Doug.