[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: tpool cleanup?
Pierangelo Masarati writes:
> Playing with Hallvard's thread debugging code I came into something
> that looks strange: slapd does tpool init/cleanup fine, while tools
> don't.
> (...)
We discussed a related issue some time ago. The whole init/cleanup
stuff in slapd is skewed. main() does ldap_pvt_thread_initialize(),
while slap_destroy() does ldap_pvt_thread_destroy(). slap_destroy()
is called from either main() or slap_tool_destroy().
Another thing I've finally noticed, and maybe the cause of this, is that
libldap_r does not initialize threading, so an application which just
links libldap_r instead of libldap will fail with some thread packages -
at least with pth.
OTOH, if the application does call ldap_pvt_thread_initialize() like
slapd does, that may fail if the program has already initialized
threading outside libldap_r - again pth is an example; pth_init() fails
if it is called several times.
libldap_r also seems to have a hack for cases where
ldap_pvt_thread_initialize() initializes tpool even when it does not
need threads, but simply uses some thread calls (like mutexes).
So, all in all I think the thread init stuff needs to be split up.
libldap_r needs to call some init routine to initialize its own
threading stuff and optionally try to initialize the thread package. If
the latter fails, the init routine should _not_ fail if the failure can
be because threading is already initialized. And the program should be
able to call the init routine with a parameter which overrides the
default guess.
Maybe ldap_pvt_thread_initialize() should just be a wrapper around that,
I'm not sure. And maybe the the caller should initialize and destroy
the thread pool explicitly instead of having
ldap_pvt_thread_<initialize/destroy>() do it. IIRC, the thread pool
should be destroyed earlier than the rest of the threading stuff: Calls
to ldap_pvt_mutex_unlock now happen after the thread pool is shut down.
--
Hallvard