apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: Terminating threads in a process, WAS: RE: [PATCH] Problems with MPM threaded
Date Tue, 17 Jul 2001 16:13:21 GMT
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 Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message