Paul Fremantle wrote:
+1 samisa. It might be hard work now, but worth it.
Also I think based on the discussion we had with James, maybe its
possible to set some boundaries. We allocate all memory within that
execution path from a buffer, and free all memory from the buffer at
the end.
Yes it is a good idea to have a buffer to solve the unreleased memory
problem. As of now, our allocator does not have a pool, but we can
easily do that. However, even with the pool, I think it is good to adopt
the best practice of releasing whatever reserved resources back to the
pool at the earliest possible. This way we could gaurentee efficient
memory use. Buffer will help us with garunteed release at the end of the
execution path, in case memory has not been released when it hits the end.
Thanks,
Samisa...
Paul
On 10/26/05, *Sanjiva Weerawarana* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
On Wed, 2005-10-26 at 07:43 +0600, Samisa Abeysinghe wrote:
> Hi All,
> There are few more memory leaks present in the axis2 C code.
> (Guththila leaks should be handled seperate IMO)
>
> I would like to propose that we use the unit tests to
isolate memory
> leak problems as much as possible and fix those then and there.
I would
> like the allocation and de-allocation to be local to a given
> class(struct) and module. We should always be providing a free
interface
> that matches a create interface for each struct, and the free
mechanism
> should be responsible of dealing with all deallocations. If we
are to
> have too much coupling in terms of memory allocation and
deallocation
> across modules and structs, we would run into great trouble in
dealing
> with fixing leaks.
>
> IMHO, it will be a good practice to be concerned of memory leaks
> right from the begining and leave no room for memory leaks as
much as
> possible. So lets try ro keep the memory leaks to *zero* :)
+1 :). I can imagine this is a bit hard but if we are careful its not
impossible!
Sanjiva.
