On Fri, Jan 23, 2004 at 02:51:27PM -0500, Greg Hudson wrote:
> On Fri, 2004-01-23 at 14:46, Sander Striker wrote:
> [Regarding svn_diff_contains_conflicts and friends:]
> > > What does being read-only have to do with needing a pool? You need a
> > > pool if any of the work you're doing requires memory allocation, whether
> > > or not that memory is interesting to the caller.
>
> > None of that work requires memory allocation. It's walking a list
> > and returns true/false depending on whether there are conflicts/diffs.
>
> That seems like it depends on the internal representation of a diff.
> Right now it's just a matter of walking a list and checking flags, but
> that's not the only possible representation. I think it's much cheaper
> to take a pool which we don't currently need than it is to find the door
> shut on performing memory allocations if we need to do so in the future.
Like I said in my email. It's questionable if that's really needed as
you pointed out. My logic in including it is as follows:
* If I didn't include it someone might say "Why didn't you do those too
while you were at it?" Then I would have make the changes, track down
all the callers, test and post a new patch. This would take me some
time to post it with some confidence that it's a good change.
* If I did include it someone might say "But those pools aren't really
needed?" By already including it my workload to make the change is
smaller here. I already know what had to be changed to make those work.
I can simply start reverting changes and regenerate a new patch.
So that was my logic. I'm not attached to those changes being there. I
did it because I figured it was the most expedient way to deal with the
issue. If there's enough complaints about those pool arguments I'll be
happy to regen the patch without that. Shouldn't take me more than 15
minutes including testing.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 23 22:08:54 2004