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

RE: mod_dav/mod_dav_svn PROPFINDS.

From: Sander Striker <striker_at_apache.org>
Date: 2002-07-01 23:06:51 CEST

> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> Sent: 01 July 2002 22:39

[...]
> Hmmm. I would be surprised if that were the fix anyway. Usually a
> caller should not be creating a subpool for one function call. Maybe
> there are rare circumstances where it's justified -- but then, those
> are the sorts of circumstances where it would be even *more* justified
> for the called function to create and free its own subpool internally!
>
> Rather, callers should use clearable subpools for unbounded loops. I
> mean loops where the number of iterations is not constant, but is
> dependent on some run-time factor, such as the number of entries in a
> directory.
>
> So, I wonder if the real problem could be the loop immediately beneath
> the above-quoted code, the loop that begins:
>
> /* iterate over the children in this collection */
> for (hi = apr_hash_first(params->pool, children); hi; hi = apr_hash_next(hi))
> {
> ... do various stuff, including at least one more use of
> params->pool, hint hint :-) ...
> }
>
> Even if subpool'ing that loop doesn't solve the problem, it is
> probably still a good idea.

/me nods

This is what I quickly hack patched, and it does help, though not resolve the
entire problem.
 
> But Ben recalls Greg Stein saying that this might actually be a pool
> usage problem in mod_dav itself, so changes in mod_dav_svn may or may
> not be part of a solution. Dunno, back to you.

I guess it is 'take a close look at mod_dav' time...

Sander

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 1 22:58:07 2002

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.