[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#4943) tpool.c pause vs. finish
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.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/