apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <d...@arctic.org>
Subject Re: Seperating cleanups from memory allocations, WAS: RE: Terminating threads in a process
Date Wed, 18 Jul 2001 03:33:09 GMT
On Wed, 18 Jul 2001, Sander Striker wrote:

> Wouldn't it be wiser to implement cleanup management as a
> seperate entity, instead of piggy backing it on allocators?

i'm not sure... 'cause the only thing i think which is missing is
something like this:

    typedef struct {
	int die_soon_please;
	int ref_count;
	apr_lock_t *lock;
    } thread_cleanup_t;

die_soon_please is initialised to 0
ref_count to 2
lock is initialised and released

to create a thread that you want cleanup for you create one of these
thread_cleanup_ts (malloc'd).  then you register a cleanup in
the "parent thread"'s pool, such as the following:

    apr_status_t thread_cleanup(void *_tc)
	thread_cleanup_t *tc = _tc;

	if (--tc->ref_count) {
	    /* thread is still around, tell it to die asap */
	    tc->die_soon_please = 1;
	else {
	    /* thread has already exited, it took care of
	     * cleaning up its pool on the way out
	return 0;

and then when the "child" thread wants to exit, it should do:

    if (--tc->ref_count == 0) {
	/* parent asked us to go away, so we get to free up the
	 * structure
    else {

and at any time the child cares to ask if the parent told it to die
it can just test tc->die_soon_please.

this basically just moves the mutexes from the common path to the less
common path of parent/child relationship.


p.s. maybe this example will help highlight why apr_lock_t is far too
generic and there should be a more lightweight thread only mutex that
doesn't require lots of extra memory allocation?

View raw message