You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by VK Sameer <sa...@collab.net> on 2005/06/02 11:28:29 UTC
Re: [PATCH]: issue #2264 - multiple locks over ra_svn - v3
On Tue, 2005-05-31 at 11:32 -0500, kfogel@collab.net wrote:
> > Yes, I definitely need to understand pool usage better.
>
> Are there specific questions that the relevant section of HACKING
> leaves unanswered? I'm a little too familiar with it now to be able
> to see weaknesses in the explanation there, unfortunately, but I'd be
> happy to help clarify anything. Plus it wouldn't hurt to expand the
> explanation in HACKING, if it's not sufficient. Let us know.
I think the points you made in this email would be useful, namely,
- Poolnames being hints to reviewers of pool usage.
- O(1) leakage vs. O(N) leakage in case of SVN_ERR causing a return
from the function without cleaning up a pool created there.
- the previous point also might help reduce worry about mixing and
matching various pools in a function.
- Using the incoming pool for data that is persistent throughout
the function.
I've probably edited your email badly in my response. My apologies if
I've misinterpreted your comments.
Regards
Sameer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: issue #2264 - multiple locks over ra_svn - v3
Posted by kf...@collab.net.
VK Sameer <sa...@collab.net> writes:
> I think the points you made in this email would be useful, namely,
>
> - Poolnames being hints to reviewers of pool usage.
> - O(1) leakage vs. O(N) leakage in case of SVN_ERR causing a return
> from the function without cleaning up a pool created there.
> - the previous point also might help reduce worry about mixing and
> matching various pools in a function.
> - Using the incoming pool for data that is persistent throughout
> the function.
>
> I've probably edited your email badly in my response. My apologies if
> I've misinterpreted your comments.
No, these are all accurate reflections of what I was trying to say.
Thanks for the summary. In r14932, I expanded that section in HACKING.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org