so while hacking up that patch to eliminate the block_freelist i thought i
could also get rid of the alloc_mutex entirely. but it appears that
currently the pool code sort of supports multithreaded access to the same
pool.
i say "sort of" because cleanups don't support multithreaded access -- no
mutex there. and cleanups of pools across threads sounds really ugly
(because we deliberately don't have async notification of threads).
but if you study the parent/child pool linking code (search for ->parent)
you'll see that whenever the parent pool is touched, it's done inside
alloc_mutex.
ages ago it was discussed that there would be a "root" pool per-thread --
and that a pool would be accessed by a single thread. this would mean
that alloc_mutex wouldn't need to be aquired to touch the parent pool.
ok studying the mpm threaded.c code i see that we give each thread a
sub_pool of pchild. but i think the following patch would be safe,
because each thread won't exit until it has done its own cleanup.
i haven't tested the patch though... what do people think?
(the real testing would include removing the alloc_mutex from apr_pools.c
code which accesses p->parent.)
-dean
Index: threaded.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/mpm/threaded/threaded.c,v
retrieving revision 1.44
diff -u -r1.44 threaded.c
--- threaded.c 2001/07/03 13:58:10 1.44
+++ threaded.c 2001/07/08 18:32:50
@@ -697,7 +697,9 @@
my_info->pid = my_child_num;
my_info->tid = i;
my_info->sd = 0;
- apr_pool_create(&my_info->tpool, pchild);
+
+ /* each thread needs its own private pool tree */
+ apr_pool_create(&my_info->tpool, NULL);
/* We are creating threads right now */
(void) ap_update_child_status(my_child_num, i, SERVER_STARTING,
