>You bet. It is rather difficult to do "iteration subpool" types of usage
>because you have to "reach into" the trail structure.
>
>Actually, my example to Ben was regarding the result pool. If you have a
>function that wants a result for some intermediate purpose, then it has to
>reach into the trail structure, tweak the result pool, call the target
>function, then change the trail back. This really breaks some of the
>encapsulation (if you will) of the trail structure.
>
>The same issue applies to the scratch pool.
>
>
It seems to me that managing memory is a good function for trails. So
why not add some methods on trail_t to manage scratch pools?
How about something like this.
void
svn_fs_trail_scr_push(trail_t *t);
/* pushes alloc_cnt
and total_size from trail_t into current scratch pool userdata */
/* creates scratch
sub-pool and replaces reference in trail_t */
/* sets both
alloc_cnt, tot_size in trail_t to 0*/:
apr_pool_t *
svn_fs_trail_scr_get_pool(trail_t); /* could be macro. It also could
have shorter name:-) */
/* he should not be
used however */
void *
svn_fs_trail_scr_pcalloc(trail_t t, apr_size_t size); /* allocates data
from pool at top O stack*/
/* increments alloc_cnt and adds size to tot_size*/
/* returns memory */
void *
svn_fs_trail_scr_palloc(trail_t t, apr_size_t size); /* allocates data
from pool at top O stack*/
/* increments alloc_cnt and adds size to tot_size*/
/* returns memory */
int
svn_fs_trail_scr_get_alloc_cnt(trail_t); /* accessor returns alloc_cnt
from trail_t */
int
svn_fs_trail_scr_get_tot_size_cnt(trail_t); /* accessor returns
tot_size from trail_t */
void
svn_fs_trail_scr_pop(trail_t *t);
/* get parent pool of
current scratch pool */
/* destroy current
scratch pool */
/* get alloc_cnt and
total_size from parent userdata and put back in trail_t */
/* replace reference to
pool back to the parent which is now the top O stack */
Another variation is to make the above an object svn_scr_pool. then he
could be used by any code with batons.
The idea is to use alloc_cnt and tot_size to make decisions as to when
to free up a scratch pool.
simple example
trail_t *t;
.....
{
svn_fs_trail_scr_push(t);
while()
{
cal_something(t);
/* optionl logic */
if ( svn_fs_trail_scr_get_alloc_cnt(t) > 1000 ||
svn_fs_trail_scr_get_tot_size_cnt(t) > 1000000 )
{
svn_fs_trail_scr_pop(t)
/* trail scratch pool is now at the level when my fucntion
was entered. */
svn_fs_trail_scr_push(t);
}
}
svn_fs_trail_scr_pop(t);
}
Now it may be neccesary to allow allocation from the parent of the
current scratch pool so the ther caller can allocate scratch inside the
loop. That could get a little confusing. I think it can be managed
safely however. It may also be nice to have access to the size of the
pool above the current pool so that more intelligent decisions can be
made about when to clear scratch subpools. And as a extension keeping
track of the size and number of counts in the whole scratch stack could
be useful as well. Each of these would create more overhead.
The rule that should never be broken is that scatch subpools must always
be pushed and popped at the same call level.
Well, thats my $.02
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 1 18:45:08 2002