Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Tue, 17 Jul 2001 09:13:21 -0700 (PDT)
From: <rbb@covalent.net>
To: Aaron Bannert <aaron@ebuilt.com>
Cc: <new-httpd@apache.org>, <dev@apr.apache.org>
Subject: Re: Terminating threads in a process, WAS: RE: [PATCH] Problems with
 MPM threaded
In-Reply-To: <20010717085407.W23346@ebuilt.com>
Message-ID: <Pine.LNX.4.30.0107170856370.1421-100000@koj.rkbloom.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 17 Jul 2001, Aaron Bannert wrote:

> On Tue, Jul 17, 2001 at 01:29:47AM -0700, dean gaudet wrote:
> > On Sun, 15 Jul 2001, Sander Striker wrote:
> >
> > > Why are we so desperate in opting out the child-pool creation?
> > > I don't really have problems with a child pool for each thread. Actually,
> > > it will make the dynamic locking a lot easier to implement if it stays.
> >
> > all threads MUST have their own private pool root.
> >
> > otherwise you're just throwing scalability away in locks.  (which is
> > proved by the claim i saw that ian got better performance by defining
> > ALLOC_USE_MALLOC on an 8-way.)
>
> I totally agree, but only as a solution in httpd.
>
>
> I also believe that we should provide this [application-specific requirement]
> outside of the basic thread support in APR.
>
> Please allow me to use pseudocode:
>
> void * worker_function(void * opaque_application_data) {
>
>    apr_pool_t *thread_pool;
>
>    create_child_pool(&thread_pool, global_root_pool);
>
>    do_thread_stuff();
>
>    cleanup_child_pool(thread_pool);
>
>    if (apr_thread_exit_makes_sense_to_call_from_inside_worker_function) {
>       int rv = APR_SUCCESS;
>       apr_thread_exit(&rv);
>    }
>
>    return NULL;
> }
>
> What I mean by this gibberish is that the pool-handling code can exist
> completely outside of our thread_creation-type functions in APR. Is there
> any reason for APR threads to do more than this (that is, just simple thread
> creation)?

We have hit an impass in my mind.  Dean and I are saying that having each
thread have it's own pool is a requirement.  Not just for httpd, but for
anything using pools.  Dean, if I am mis-interpreting you, then I am
sorry, and please correct me.

Aaron,  you disagree.  you want each app to make that decision on their
own.  I see no way to implement that in a thread-safe manner.

So, I would suggest that we approach this problem in another way.  My ONLY
goal for APR is to make a library that is useful for cross-platform
development and eases the pain of cross-platform development for
developers.  That was the goal when I created APR, and my original test
case was the Apache web server.

I believe that the problem is that the threaded code is creating the
pool, and not advertising it to the thread itself.  This is an easy thing
to fix.  I do not agree that every APR app that uses threads should have
to create their own thread pools.  That is wasted effort by every APR app.

I would like to see a conclusion to this thread quickly.  So, could people
please post their desires quickly, and what they want to see from this.

Ryan

_____________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net
-----------------------------------------------------------------------------