You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@httpd.apache.org by Sander Striker <st...@apache.org> on 2001/07/14 21:16:17 UTC

RE: Terminating threads in a process, WAS: RE: [PATCH] Problems with MPM threaded

Right, changed the subject line again, the typo was hurting my
eyes and I wouldn't want a thread with that subj. line.
Sorry for reposting.

Justin:
>> By having the possibility of having other children processes, you now
>> need a mechanism to kill all threads in the same process efficiently.
>> You'd need to kick them out of the accept mutex, but I'm not seeing
>> how that's going to happen quickly.  -- justin
 
Ryan:
> You need to be able to kill all threads in a process efficiently
> regardless.  We will always need to be able to re-spawn processes that
> die, and we will always have the concept of MaxRequestsPerChild.  If a
> process is going to die and be replaced, then we need to kill all the
> threads in that process as quickly as possible.  Only allowing one
> process at a time doesn't remove that requirement.

The way I see it, each process has a single pool instance as the parent
for all the threads. Resetting or destroying that pool should effectively
kill all threads. What am I missing?

Sander

Re: Terminating threads in a process, WAS: RE: [PATCH] Problems with MPM threaded

Posted by Justin Erenkrantz <je...@ebuilt.com>.

On Tue, Jul 17, 2001 at 06:28:37PM -0500, William A. Rowe, Jr. wrote:
> Yes, yes, yes.  Can we please split the concept of a heirarchial parent (the
> 'creator' thread's or process pool, in this case) from the allocation parent
> (the actual give me memory for my pool from ... here!)  Then we have an 
> "OS Knows Best" malloc/free mpm for threading, just as you suggest.
> 
> This solves your thread-specific requirements and our scoping issues, along
> with fixing the 'walk the chain of pools for a block' problem, both at once.

Okay, I will try and commit something into the SMS code that does 
this.  If I understand you, there will be one parent which will handle
allocation and another that will handle cleanups.  This should handle
your concerns about a thread that didn't exit properly and my concern
about having a unnecessary locking in the allocation code.  Deal?

I'll make it default to having both parents be identical, and the
apr_thread_create call can set it to be null (or a std. SMS).

The only problem is the SMS code is chock-full of subtle race
conditions right now.  We *really* need more eyes on this code.
-- justin

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

Posted by 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

Posted by 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

Posted by 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

Posted by 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?

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

Posted by 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

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

Posted by 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