[Date Prev][Date Next] [Chronological] [Thread] [Top]

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
slapd stopped.
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

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it