[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-pim
Subject: Re: [Kde-pim] Threaded ldap search class
From: Sean Harmer <sh () theharmers ! co ! uk>
Date: 2007-04-11 7:16:47
Message-ID: 200704110816.47293.sh () theharmers ! co ! uk
[Download RAW message or body]
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@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic