httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: pool performance in the worker mpm
Date Fri, 23 Nov 2001 19:30:07 GMT
Hi all,

> -----Original Message-----
> From: Brian Pane [mailto:bpane@pacbell.net]
> Sent: 23 November 2001 20:19

> Ryan Bloom wrote:
> 
> [...]
> 
> >We tried adding a pool per worker-thread, but the code ended up 
> being much
> >more complex than today's logic.
> >
> >What we really need to do is just remove the mutexes from the 
> pools.  We already
> >state that each thread must have it's own pool, so this 
> shouldn't be too hard
> >
> 
> I think we could partially remove the mutexes, although we won't be able
> to remove them completely without a design change in worker.
> 
> The problem is that the ptrans pools are children of a pool owned
> by the listener thread, so during apr_pool_destroy() on ptrans we
> rely on the mutex in apr_pool_destroy() to prevent race conditions
> in the parent pool.
> 
> But we could still optimize away the mutex operations for subrequests,
> which in some cases would be a major win.
> 
> Thus I'm thinking of extending the pool API with something like:
> 
>   /* Just like apr_pool_create(), except that the new pool and all
>    * its descendants may be used only by a single thread.  (This
>    * optimizes away thread synchronization overhead in the allocation
>    * code.)
>    */
>   apr_status_t apr_pool_create_for_thread(apr_pool_t **new_pool, 
> apr_pool_t *parent);
> 
> In apr_pool_destroy(), we'd still have to do the locking unless
> the parent also has its "no_thread_synchronization" flag set.
> 
> Unless anybody sees an obvious problem with this, I'll prototype and
> profile it.

I don't have a problem with it.  I just want to state that I have quite
some pools code sitting on my machine which I would like to profile and
possibly integrate.  I can work on this tomorrow for a bit.

> --Brian

Sander

Mime
View raw message