[gomd-devel] <TECH> tech survey for the daemon memory management...

[Gian Paolo Ghilardi]

Hi all.

As said yesterday, I'm working on a memory usage control facility for the
daemon.
After a long search, I've found a outstanding implementation of smartPointer
that autodetectes memory leaks, null pointers,...


THE PROBLEM
Unfortunately this implementation cannot handle pointer changes, so the
following code snippet (notice ATM we're using this code) fails with
smartPointers.

smartPointer<connHandler> myConnHandler;  //(#1) this is the smart version
of connHandler* myConnHandler
while(true)
{
    ...
    myConnHandler = new connHandler(...); //(#2) myConnHandler is a conn
handler.
                                                                   //The
class extends the commonCpp's Thread object
                                                                   //the
"new" increments the reference counter
    myConnHandler.detach();                        //start the Thread
    ...
}

This code creates a new object/Thread for each new client connection.
As the point #2 depends from point #1, we have different objects but the
smartPointer counts as it had just one object (notice the point #1).
Notice this causes a logical error while counting the references (we have a
refernce couter for _all_ the connHandlers!) and the smartPointer signal
this situation (erroneously) as a memory leak (if a object is closed, the
references should be 0, but the reference counter is shared amongst all the
objects so there's an error!).


SOLUTION (?)
The solution si simple: we can use a LinkedList (this situation also occurs
without using the smartPointers!).

smartPointer<connHandler> myConnHandler;  //(#1) this is the smart version
of connHandler* myConnHandler
list< smartPointer<connHandler> > chList;      //list of active conns
while(true)
{
    ...
    myConnHandler = new connHandler(...); //(#2) myConnHandler is a conn
handler.
                                                                   //The
class extends the commonCpp's Thread object
                                                                   //the
"new" increments the reference counter
    myConnHandler.detach();                        //start the Thread
    chList.push_back(myConnHandler);        //while inserting, the list
creates a copy of the object, so we have many different objects
                                                                   //and we
have no problem with the smartPointers and the internal reference counter.
    ...
}


JUST A CHANGE OF POSITION...
The problem just moved... ;)
Now we have to clean the LinkedList when the conns are closed.
The idea is simple, create a Thread ("Garbage Collector") that periodically
cleans the list (it sets to NULL all the closed connHandlers and deletes
removing them from the list).


THE QUESTION.
I've tested the stuff (works fine) but... a question appeared in my mind:
"yes, this stuff is cool, but we _really_ need that?".

I need comments about this stuff, please.... :)

PS: notice the overheads are minimal (by tuning up the GC facility) and a
such kind of memory management is absolutely fantastic.
But the complexity grows a lot and I think this can break the "Spirit of
Simplicity" that permeates the whole gomd project.

Byez.

<rejected>