> From: kfogel@newton.ch.collab.net [mailto:kfogel@newton.ch.collab.net]On
> Behalf Of kfogel@collab.net
> Sent: Friday, August 15, 2003 7:49 PM
> Garrett Rooney <rooneg@electricjellyfish.net> writes:
>> My only objection is that I find
>>
>> apr_pool_t *subpool = svn_pool_create(pool);
>>
>> a lot easier on the eyes (and the vertical whitespace) than
>>
>> apr_pool_t *subpool;
>>
>> apr_pool_create(&subpool, pool);
>>
>> It's not a huge objection, but there it is if anyone cares. Of
>> course, this is probably because I've only really used APR in the
>> context of Subversion, so I never got used to the other pattern.
>
> I kind of feel the same way, actually.
I am -0 on the change myself. It's a lot of churn with not much
gain to replace all the calls. It's more off a post-1.0 cleanup
task.
> I'd rather keep the wrapper function, even if it stops doing anything
> special (as opposed to getting rid of it, and discovering later that
> we really did want a hook on pool creation -- for example, for certain
> kinds of instrumentation).
By that analogy we might want to invent more wrappers since we may one
day come up with something we could do there. Seriously, what kind
of instrumentation. If you are talking about debug code related to
pools, that should be in APR, not in libsvn_subr. I can't think of
anything specific to SVN in that respect.
> Also, making such a sweeping change now will invalidate a lot of
> patches <+shudder+>. If the change had a large benefit, that might be
> worth it, but I don't think this one does.
I think you're right. I will remove the unused code though and
turn it into a simple wrapper.
I started looking at this because the cmdline client is single threaded.
Therefor it can have its own _mutexless_ allocator. That save more
than a couple of calls to apr_thread_mutex_[un]lock when apr_palloc has
to call on it's allocator. Not to mention everytime a subpool is created
or destroyed.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 15 21:52:30 2003