httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, VF-Group <ruediger.pl...@vodafone.com>
Subject Re: svn commit: r603502 - /httpd/httpd/trunk/modules/proxy/proxy_util.c
Date Wed, 12 Dec 2007 11:16:46 GMT


> -----Ursprüngliche Nachricht-----
> Von: Nick Kew 
> Gesendet: Mittwoch, 12. Dezember 2007 12:08
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r603502 - 
> /httpd/httpd/trunk/modules/proxy/proxy_util.c
> 
> 
> On Wed, 12 Dec 2007 07:44:03 -0000
> rpluem@apache.org 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



Mime
View raw message