gomd-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Matthias Rechenburg
Subject: Re: [gomd-devel] <TECH> tech survey for the daemon memory management...
Date: Tue, 7 Oct 2003 10:05:57 +0200
User-agent: KMail/1.4.3

Hi JP,

On Dienstag 07 Oktober 2003 00:09, Gian Paolo Ghilardi wrote:
> 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... ;)

hehehe, yep ;))

> 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?".

good questions, this stuff looks really cool .......... but the gomd
is working nice without it ;)

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

to my mind we do not need it 
(i like the current code-base without smart-pointer)
e.g. the chpox support is much more serious.

>
> 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.

yep

>
> Byez.
>
> <rejected>
>

have a great day,

Matt
-- 
E-mail  :  address@hidden
www     : http://www.openmosixview.com
an openMosix-cluster management GUI

I think I go insane; a silent virus takes control and puts me on the screen
My memory on empty hole; no one to hear me scream
HIGH TECH, HIGH TECH -- LOW LIFE                      





reply via email to

[Prev in Thread] Current Thread [Next in Thread]