apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <d...@arctic.org>
Subject multithreaded pools?
Date Sun, 08 Jul 2001 18:34:25 GMT
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

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

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.)


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,

View raw message