[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1705060 - in /subversion/trunk/subversion/libsvn_ra_serf: ra_serf.h serf.c util.c

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 24 Sep 2015 18:15:50 +0100

Ivan Zhakov wrote:
> Julian Foad wrote:
>> Ivan Zhakov wrote:
>>> [...] we also have many functions that accepts just POOL and use
>>> it as scratch pool. And we also have many functions that uses it as
>>> result pool.
>> Yes, we do have many of those. That was the Old Way. Naming the pools
>> 'scratch_pool' or 'result_pool' is the New Way. We seem to generally
>> agree that is better, and sometimes we rename the single 'pool'
>> argument of old functions to either 'scratch_pool' or 'result_pool'.
> Could you please give me link to the thread where we discussed The New
> Way? Yes, we use result_pool/scratch_pool, but I don't remember
> discussion about never using just one POOL.

I don't know if this was ever explicitly discussed. (The thread where
the two-pools paradigm was first publicly is: Subject "result_pool and
scratch_pool", from Greg Stein, on 2008-10-06, archived at e.g.
http://svn.haxx.se/dev/archive-2008-10/0268.shtml )

> One problem with single pool argument named result_pool is performing
> temporary allocations. I find temporary allocations in result_pool
> slightly confusing.

I agree with that. That is a good point. Maybe the argument it is not
so clear. I have sometimes found that situation, and I have wondered
if the best thing is to declare "apr_pool_t *scratch_pool =
result_pool;" inside the function, but I don't often do that.

- Julian
Received on 2015-09-24 19:16:28 CEST

This is an archived mail posted to the Subversion Dev mailing list.