[Date Prev][Date Next]
Re: tpool cleanup?
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
thr_debug.c:619: ldap_pvt_thread_exit error: !threading_enabled is 1
Abort (core dumped)
(at least on Solaris 8).
Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team
Via Dossi, 8 - 27100 Pavia - ITALIA