apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@ebuilt.com>
Subject Re: Terminating threads in a process, WAS: RE: [PATCH] Problems with MPM threaded
Date Tue, 17 Jul 2001 15:54:07 GMT
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


Mime
View raw message