[Date Prev][Date Next]
RE: back-ldap, libldap_r
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:
>> Note that this is just food for thought...
>> 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
>> >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