RE: back-ldap, libldap_r

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 03:25 PM 12/21/2002, Howard Chu wrote:
>I vaguely recall reading that before, must have been on the ldapext list
>because I didn't find mention of it in the -devel archives.
>
>There's a lot of work involved in doing this right. Following the lead of
>those drafts would be a good step toward doing it right. My suggestion was an
>expedient way to move a little forward without introducing too much change.
>(OK, ok, my suggestion is a hack. :)
>
>I think the concept of a global ldap_errno is not viable.

No worse than the concept of errno.

>The fact that Unix
>errno's behavior changes on some platforms based on whether or not you
>included the proper header files and defined -D_REENTRANT at compile time is
>an unending source of trouble.

A well-designed errno system can support both threaded and
non-threaded environments without #ifdefs.

>It would be much cleaner to just make all the
>API functions return their errno,

Of course.  The goal of the errno draft was to add some
error handling without changing the function signatures.

A far better solution, in the long run, would be to
redesign the whole API.

>this way the error reporting behavior would
>be consistent regardless of compile-time switches. Many of the API functions
>do this already, so it's a question of rewriting the definitions of the
>functions that don't.

Well, I'd say that some of the abstractions are blurred in the
current API.  In particular, a session handle shouldn't encompass
multiple sessions.  Likely one should have a "directory handle"
which facilitated operations spanning multiple "sessions handles".

Also, the session API should be more 1-1 with the protocol.  There
really shouldn't be any LDAP_OPTs to set operation parameters.
But I digress.

Basically, I think we agree that the current API has significant
design flaws.  But I think we also agree that we don't have time
and/or energy to design a new API.  So we Band-Aid the old API
as best we can to do the things we need it to do.

>And while we're thinking about redefining the API, let's finish eliminating
>dynamically allocated (struct berval*) results from the code base. There's no
>good reason for the libraries to operate this way by default. These things
>get alloc'd pointlessly, they are most frequently free'd again within two
>lines of their being returned. (Unless the caller forgot and it leaked...)
>They should be real structs supplied by the caller. Let the caller copy into
>a newly allocated struct if needed. Most often it's not.
>
>We would do well to eliminate/revamp ber_alloc and friends. Allocate a large
>ring buffer per connection and do away with individual ber_buffer mallocs.
>This would not only speed things up, it would also remove another potential
>source of memory leaks.
>
>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>  Symas: Premier OpenSource Development and Support
>
>> -----Original Message-----
>> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>
>> The other alterative is to do something like:
>>
>> http://www.watersprings.org/pub/id/draft-zeilenga-ldap-c-api-c
>> oncurrency-00.txt
>>
>> Note that this is just food for thought...
>>
>> Kurt
>>
>> At 01:02 PM 12/21/2002, Howard Chu wrote:
>> >Something I'd be interested in trying out would be adding
>> some mutexes
>> >libldap to allow multiple threads to submit requests on the
>> same handle. I
>> >could do pretty much the same thing in back-ldap but I think
>> it could be
>> >better done in the library.
>> >
>> >Need a mutex for each request and response queue. For
>> results we need to
>> >tweak try_read1msg() and wait4msg() such that it unlocks
>> (optionally yields)
>> >and relocks the response mutex before looping back when it
>> hasn't found the
>> >requested msgid. This way multiple threads can wait on their
>> responses
>> >without too much hassle.
>> >
>> >  -- Howard Chu
>> >  Chief Architect, Symas Corp.       Director, Highland Sun
>> >  http://www.symas.com               http://highlandsun.com/hyc
>> >  Symas: Premier OpenSource Development and Support