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
