On Sat, 2006-04-01 at 12:08 +0200, Hallvard B Furuseth wrote: > 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.
Another issue that's happening right now is that ldap_pvt_thread_exit() may be called even if no ldap_pvt_thread_pool_submit() was issued (e.g. try starting slapd and killing it before any operation is run); this causes the thread debug build to fail with slapd shutdown: waiting for 0 threads to terminate slapd stopped. thr_debug.c:619: ldap_pvt_thread_exit error: !threading_enabled is 1 Abort (core dumped) (at least on Solaris 8). p. Ing. Pierangelo Masarati Responsabile Open Solution OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: [EMAIL PROTECTED] ------------------------------------------
