[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/