[Ns-developers] yans memory management simplication
Mathieu.Lacage at sophia.inria.fr
Sun Apr 23 09:56:53 PDT 2006
Recently, because I had a bit of free time to think back to the design
of the yans APIs, and because I was able to go back to a bunch classic
texts on c++ api design, I began to try to figure out a few ways in
which the yans memory management scheme could be simplified. This email
is a summary of what the current yans memory management scheme looks
like, and how we could change it. Feedback would be most welcome.
Yans has a bunch of rules:
- none of the public yans APIs take ownership of raw pointers. That
is, if a method takes a raw pointer, it will _not_ delete it itself.
This means that if a user allocates an object with new, he will have to
delete it himself.
- Packets are reference counted pointers: that is, once a Packet is
created with a new statement, it should be managed with pairs of ref and
unref calls to manage the packet reference counts.
- Callbacks and events are the only exception to these rules: both of
them are created with a call to new (most often hidden behind a call to
make_event or make_callback) and are given to a method which takes
ownership of the callback or event. The event will always be deleted by
the Simulator class and the callbacks must be explicitely deleted by the
callback invoker once it is done with the callback.
Clearly, it would be desirable to eliminate some of the exceptions to
the first rule and the goal would be to change the by-pointer semantics
to by-value semantics which are automatically copied and destroyed by
the c++ compiler.
Callback objects _must_ be polymorphic at runtime because we do not want
to hardcode in the callback caller knowledge about the callee: it should
be possible at runtime to provide different callees to the same caller.
To achieve this, we clearly need to keep a callback pointer somewhere so
to give this pointer value semantics, we can provide a smart pointer
which does a copy for each assignment and deletes its pointer in its
destructor. This is simple to implement, and could be later optimized
with a reference-count or reference-list to avoid spurious new/deletes
upon assignments. The result would be a callback object which users do
not need to explicitely delete. Clearly, this would have saved me quite
a few memory leaks so I expect this to be a major gain for any other
Packet objects could be wrapped in a smart pointer which handles the
reference count: this would allow the users to forget about the
reference count. It would have saved me quite a few memory leaks again
so, I expect this would be a major gain. The idea would be to name the
smart pointer Packet and rename the current Packet pointer to
For now, I don't see any way to deal correctly and simply with the Event
class. I also don't see much point and gain in simplifying its memory
management because it just won't get much simpler for most users and I
am not really sure it would simplify the implementation of the Simulator
class and the event template.
I have a mostly working implementation of the callback smart pointer and
an update of the codebase in my local tree. I am not planning to keep
working on it until the beginning of may so there is a reasonably large
window of opportunity for comments next week. As far as the Packet class
is concerned, I have not even started working on it so, there is plenty
of time to discuss it in case someone feels like it.
More information about the Ns-developers