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)?
-aaron
