Seperating cleanups from memory allocations, WAS: RE: Terminating threads in a process

[Sander Striker <st...@apache.org>]

[...]
>> Are you saying you want the thread function to have access to both a
>> "scope" pool as well as an "allocator" pool, in case they are different?
> 
> I've officially graduated to the rbb (insert a decent name here) club :-)
> 
> Thank you, yes, scope pool defines teardowns such as cleanups, 
> while the allocator
> pool addresses our performance concerns :)
> 
> An obvious test is that 'allocator' is unique (e.g. thread 
> private), a parent 
> (at any depth) of the 'scope' pool, or the 'scope' pool itself.

Well, looking at this it seems that the cleanups need to be
hierarchial (almost) all the time.  The allocators seem to be
needing to break the hierarchy for performance reasons.

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

Sander

Re: Seperating cleanups from memory allocations, WAS: RE: Terminating threads in a process

[Aaron Bannert <aa...@ebuilt.com>]

On Tue, Jul 17, 2001 at 08:33:09PM -0700, dean gaudet wrote:
[snip]
> 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?

Oh don't get me started on that again... ;)

I'd LOVE to get some really lightweight (intraprocess) mutexes into APR...
Something akin to true POSIX mutexes would be fantastic.

-aaron

Re: Seperating cleanups from memory allocations, WAS: RE: Terminating threads in a process

[Aaron Bannert <aa...@ebuilt.com>]

On Tue, Jul 17, 2001 at 08:33:09PM -0700, dean gaudet wrote:
[snip]
> 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?

Oh don't get me started on that again... ;)

I'd LOVE to get some really lightweight (intraprocess) mutexes into APR...
Something akin to true POSIX mutexes would be fantastic.

-aaron

Re: Seperating cleanups from memory allocations, WAS: RE: Terminating threads in a process

[dean gaudet <de...@arctic.org>]

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;

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

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

    apr_pool_destroy(my_root_pool);
    apr_lock_acquire(tc->lock);
    if (--tc->ref_count == 0) {
	/* parent asked us to go away, so we get to free up the
	 * structure
	 */
	free(tc->lock);
    }
    else {
	apr_lock_release(tc->lock);
    }

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.

-dean

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?

Re: Seperating cleanups from memory allocations, WAS: RE: Terminating threads in a process

[dean gaudet <de...@arctic.org>]

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;

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

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

    apr_pool_destroy(my_root_pool);
    apr_lock_acquire(tc->lock);
    if (--tc->ref_count == 0) {
	/* parent asked us to go away, so we get to free up the
	 * structure
	 */
	free(tc->lock);
    }
    else {
	apr_lock_release(tc->lock);
    }

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.

-dean

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?