Howard Chu wrote:
Brett @Google wrote:
Perhaps the ability to run a backend(s) in a seperate thread of execution, and also maybe the ability to run arbitrary threads in the server core for things such as cache managment, without having to implement a backend.We tried cache pruning in a separate thread before. It doesn't make anything faster. Threads aren't a magic solution to everything. Frequently they're not the solution to *anything*.
Just to clarify - in back-bdb/hdb, we tried putting the cache pruning in a separate thread. The problem was that if the cache was full and the slapd was fully loaded, it was very likely that the cache thread would not get a chance to run until long after the cache had grown too large. Thread scheduling is non-deterministic, and if there are a lot of LDAP requests going into the thread pool, you can't guess when the cache thread will get to start, and have no idea when it will finish.
In the pcache overlay, cache pruning still runs in a separate thread. While the same constraints apply, the actual job is different, so it works fine.
As for "cache management, without having to implement a backend" - isn't that exactly what the pcache overlay provides? What are you asking about?
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/