httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: pool performance in the worker mpm
Date Fri, 23 Nov 2001 19:19:09 GMT
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.

--Brian




Mime
View raw message