On 24.09.2015 19:15, Julian Foad wrote:
> 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.
Only old functions that have a single apr_pool_t parameter called 'pool'
should be using it as both a scratch and result pool. Any new functions
that both kinds of allocations should take two pool parameters, and it's
up to the caller to select which pools to pass.
Temporary local scratch pools should be very rare indeed; most of the
uses I've seen (outside of bindings) are in compatibility wrappers.
We've not been entirely consistent in following these "rules" but
there's a really thin line between "entriely consistent" and "stubborn
Received on 2015-09-24 19:30:39 CEST