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/
