W3C home > Mailing lists > Public > www-lib@w3.org > July to September 2000

Re: Question regarding Memory handling

From: <jose.kahan@w3.org>
Date: Thu, 17 Aug 2000 15:56:08 +0200 (MET DST)
Message-Id: <200008171356.PAA09065@tuvalu.inrialpes.fr>
To: Olaf Walkowiak <olaf@sevenval.de>
CC: www-lib@w3.org
Hello Olaf.

In our previous episode, Olaf Walkowiak said:

I let other people correct me... and my disclaimer "I'm not the original
architect of libwww" in case you have other comments :)

libwww does reserve some memory for caching... I can cite the anchors
of everything you have visited, authentication trees where passwords are
kept, DNS intelligent caching, ...

The rest of the memory is being freed every time a request ends.

These having been said, you may need to change the allocation functions
case by case and make calls to one persistent pool and calls to the non
persistent pool as needed. And it may be too complicated as some functions
like StrAllocCopy would need to be rewritten to use the two pools...

Is your motivation in using a pool is to free any outstanding memory when
the application or a request dies? I think that is Apache's motivation.

We still have some memory leaks in libwww, but I don't think they are so
many of them remaining, from the Insure runs I have done on it. Again,
I have only tested some limited cases.

Hope this info is helpful.


The insure runs I have done of libwww don't show so mu
> I would like to use my own memory allocation functions. Those
> functions will work on memory pools with different lifetimes (like
> apache does).
> There are two pools, one has the same lifetime as the application, the
> other is destroyed from time to time. During program startup and
> Library inititalisation, memory is taken from the persistent pool,
> in the "working loop" memory is taken from the non persistent pool.
> So if the Library itself allocates memory while the non persistent
> pool is active, it may be gone away later => not good.
> My question: Does Libwww allacote memory (after initialisation) that
> is not freed f.e. for caching purposes?
Received on Thursday, 17 August 2000 09:56:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:53 UTC