h.b.furuseth@usit.uio.no wrote:

Howard Chu writes:

...

...

tpool.c breaks if there are multiple pools. The simplest solution seems to be to remove support for multiple pools. The problem is thread_keys[]. It is shared between pools, but:

slapd only uses a single pool, and that's really the only use case we care about. In fact it makes no sense to support multiple pools, because we have no mechanism to assert scheduling priorities of one pool over another.

I'm afraid I did not think of scheduling priorities at all, only bugs. But it certainly makes things simpler if we remove multiple pools.

Simple documentation of how tpool should be used may remove some of my concerns - or how it _is_ used, since it's only used in slapd. (Several probably only are problems if it is used as a library feature. tpool depends on being used the way slapd is using it. I've wondered what it's doing in libldap_r/ instead of in slapd/.)

One thing to remember, which has been discussed before - all of libldap_r exists solely for the benefit of slapd. The only "official" LDAP API is what was defined in the expired C API draft, and that draft never addressed reentrancy issues. Any use of libldap_r outside of slapd is and always will be unsupported; any bugs that might exist solely due to unintended usage are not our concern.

When we finally get the time to write up a new C API we can worry about where to draw the line between the library and slapd code but for now it's all (philosophically) private to slapd.