On Thu, 2003-06-19 at 11:37, Han The Man wrote:
> > > I was under the impression that they aren't leaks but rather
> > > inefficient pool usage.
> >
> >Ha! What's the difference? The phrases "memory leak" and
> >"inefficient pool usage" both mean the same thing: that somewhere
> >you're allocating memory, but not freeing it when you should.
>
> I'd say there's a big difference. Inefficent pool usage indicates that the
> memory will be reclaimed after the operation has completed. A leak does not.
> Or am I wrong?
Yeah, but if the inefficient usage is in the top pool, or it's so
inefficient in a high level pool that you can't finish the operation,
they are functionaly equivilent. At least in UNIX, as a general rule,
you can't leak memory permanently with malloc or brk, when your process
dies, all the resources are freed (shared memory might not be freed).
Subversion in my experience frequently has lots of problems with pool
usage. As I recall that was the first mail I sent to the list (that and
asking why the BDB took up so much space relative to the CVS repository
I was converting).
Wonder if APR has a way you can tell it, never give me more then X bytes
of memory, or have APR keep track of peak memory usage, so it could be
regression tested for. The problem is that the memory regression test
might involve a lot of files and take a lot of time.
Kirby
>
> _________________________________________________________________
> Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> http://join.msn.com/?page=features/featuredemail
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 19 18:47:51 2003