[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: back-ldap, libldap_r
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. 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. It would be much cleaner to just make all the
API functions return their errno, 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.
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