Re: tpool cleanup?

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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