Graham,
thanks for the explanations and the hint to mod_proxy. I am now able to use
pools/subpools and bucket_alloctors in a better way which improves overall
performance.
Just for the record: the important thing to learn for me was that there is
another layer underneath apr_pool_t called
More thoughts...
On Fri, Mar 20, 2015 at 12:00 PM, Yann Ylavic ylavic@gmail.com wrote:
While pool (allocator) allocations are not thread-safe, creating a
subpool is, and each thread can than use its own pool (this model is
often used with APR pools).
This tells nothing about pool
Hi Stefan,
On Fri, Mar 20, 2015 at 10:12 AM, Stefan Eissing
stefan.eiss...@greenbytes.de wrote:
Just for the record: the important thing to learn for me was that there is
another layer underneath apr_pool_t
called apr_allocator_t which is not thread-safe by default - but can be made
so.
Dear Apache httpd enthusiast,
In just a few weeks, we'll be holding ApacheCon in Austin, Texas, and
we'd love to have you in attendance. You can save $300 on admission by
registering NOW, since the early bird price ends on the 21st.
Register at http://s.apache.org/acna2015-reg
ApacheCon
Yann,
the positive effect of the recycling of subpools by the allocator is
measureable in performance by me. Without a mutex'ed allocator however, the
destruction of subpools did crash on me (but it might also be another bug in my
code, of course). First, I resolved to using root pools for
On 20 Mar 2015, at 3:19 PM, Stefan Eissing stefan.eiss...@greenbytes.de wrote:
Looking at the code in httpd, mpm_worker and mpm_event seem to create own
alloctors for the pools they use and those allocators are not protected by a
mutex. And need not, since normally a connection and all its
Am 23.01.2015 um 11:09 schrieb Yann Ylavic:
On Mon, Oct 27, 2014 at 1:40 PM, j...@apache.org wrote:
Author: jim
Date: Mon Oct 27 12:40:34 2014
New Revision: 1634520
URL: http://svn.apache.org/r1634520
Log:
Merge r1621367, r1621372, r1625952 from trunk:
PR53218
Allow for longer worker names
