New LDAP C API

[Howard Chu]

David Boreham wrote:
> Love Hörnquist Åstrand wrote:
>
>>> This was one of Kurt's points, but I take it to mean "free- 
>>> threaded" i.e. the same library should work with or without  
>>> threads. The calling app should provide threading/locking callbacks  
>>> if needed.
>>
>>
>> For me free-threaded means no locking done at all, because its not  
>> needed.
>
> It doesn't mean that to me. It means that there are no
> unreasonable constraints imposed on the application related
> to concurrency -- here's your handle, go use it freely -- no
> 'oh well, you can't use that handle in a different thread' or
> 'oops, no you can't read from it in one thread while writing
> in another thread' etc etc. The application doesn't need to
> worry about tripping over concurrency hazards inside the
> library, modulo stupid things like closing a handle in one thread
> while still inside a call on the same handle in another thread.
> OS handles (fds etc) usually work like this.

Agreed.
>
> I'm not sure about the current OL library, but I do know that
> the Mozilla SDK has some evil concurrency issues because when
> I wrote some code in the server that accessed the same handle
> from two threads all hell broke loose. I had to introduce some
> unpleasant work arounds in my code.

Yes, I had to rework the OL libldap_r when I added connection pooling to 
back-ldap 4 years ago. It was definitely a mess, but it's mostly under 
control now.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  Chief Architect, OpenLDAP     http://www.openldap.org/project/