> -----Ursprüngliche Nachricht----- > Von: Nick Kew > Gesendet: Mittwoch, 12. Dezember 2007 12:08 > An: [email protected] > Betreff: Re: svn commit: r603502 - > /httpd/httpd/trunk/modules/proxy/proxy_util.c > > > On Wed, 12 Dec 2007 07:44:03 -0000 > [EMAIL PROTECTED] wrote: > > > Author: rpluem > > Date: Tue Dec 11 23:44:02 2007 > > New Revision: 603502 > > > - request_rec *rp = apr_pcalloc(c->pool, sizeof(*r)); > > + request_rec *rp = apr_pcalloc(r->pool, sizeof(*r)); > > (more of the same). > > OK, that looks safe to me. > > Which begs the question: why was it using the connection pool before? > I'm reluctant to believe there was no reason, until we've exhausted > other possibilities.
The connection memory pool was a different memory pool before. It was the memory pool of the front end connection. Now it is the memory pool of the backend connection pool connection. See also http://svn.apache.org/viewvc?view=rev&revision=603237 http://svn.apache.org/viewvc?view=rev&revision=602542 If we would use r->connection->pool instead of r->pool it would be exactly the same as before the two revisions above, but regarding the pool livetimes I think r->connection->pool lives too long and thus using r->pool wastes less memory. Regards Rüdiger
