[Kde-pim] Threaded ldap search class

[Sean Harmer]

Hi,

On Tuesday 10 April 2007, Szombathelyi György wrote:
> Oh, thread safety. This is harder than you (and me) thinked. I found out
> that the OpenLDAP client libs are absolutely _not_ thread safe, even if you
> link to _r versions, so the above use-case can also fail, if an app starts
> more than one search parallel. E.g it could call non-reentrant glibc
> functions, simply a gethostbyname() can broke the app (and if you create
> connections in multiple threads that will happen!).
> Here's a thread which is not promising:
> http://www.mail-archive.com/openldap-software%40openldap.org/msg08198.html
I think that you're right. This looks like a non-starter from that thread (no 
pun intended). It looks like we would have to patch the openldap clients libs 
first before we can rely on it being thread safe. I really don't have the 
time to look into that before the API freeze! Although I've not looked at the 
openldap source code so I can't say for sure yet.

>
> The possible solutions I can imagine:
> - Force the users of the class to use only one search thread. But It can
> break too, when you mix LdapThreadSearch and other LdapOperations methods.
> - Try to put only ldap_result (your waitForResult() func in LdapOperation) 
> to the thread, and pray that this lonely function is reentrant.
Hmm, I don't like relying on blind luck. In my experience someone will always 
break it.

> - Give up this great thing, and use the event loop again, but be smarter:
> don't block till a message arrives, but poll (call waitForResult with 0
> msec - but that can be slow, and CPU consuming), or block for a small
> amount of time (e.g. 10 msecs).
I think the safest option for now will be to use the event loop and block for 
a short period of time as you suggest. This will at least make it *appear* 
non-blocking with slow ldap connections.

>
> >Once I'm done with those changes, I'll merge it into LdapSearch and post
> > it here for comments and testing.
>
> Now do you feel you'll want to to this? :)
More scared now :-)

> Of course my reasoning could be totally wrong, I'm hoping this, too!
Maybe, but I think that you're correct.

>
> Eventually, If you finish the threaded version, I'd like to torture it with
> 100 LdapSearch objects :))
Maybe for KDE 4.x where x >= 1. I'll keep plugging away at it locally to get 
the API straightened out - this shouldn't take long. When I have it in a 
reasonable shape, I'll post it and then we can see if it works and how much 
work may be required in libldap_r to make it reliable. It would be a shame to 
let it die and it must be possible (given enough time and effort).

I really need to get working on the ldapmodel again though. My thoughts for 
this are to have a single class, LdapModel, derived from QAbstractItemModel 
And then two convenience proxy models that filter it to display the 
structural aspects of the ldap tree and the contents of a single ldapobject 
in the hierarchy. I need to do some more thinking on whether this is a 
sensible approach though.

Regards,

Sean
_______________________________________________
kde-pim mailing list
kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/