Bugzilla – Bug 89
Not possible to free nodes before the end of a simulation
Last modified: 2008-10-22 15:53:50 EDT
You need to log in before you can comment on or make changes to this bug.
Currently it is not possible to really free nodes destroyed during a simulation; they are freed only at the end of the simulation. This may--or not--cause memory problems in certain styles of simulation scripts. I just wanted to raise the issue here, for future consideration.
There are a lot of issues to consider here: Implementation: the main issue to make it possible to free nodes before the end of simulation is to allow a user to remove a node from the NodeList. The big problem with such a change is that the index of a Node in a NodeList is also the NodeId. The main reason behind this implementation detail is that we wanted to make it really efficient to perform a lookup by node id in the NodeList. This lookup is performed in the tracing code when it wants to know from which node a trace event is coming from. Specifically, it is the ArrayTraceResolver which is storing this nodeid as an index in a TraceContext. While fixing bug 98, I spent a good while thinking about this implementation issue. There are a lot of implementation options: - we could just mark freed nodes as zero in the NodeList and implement a new NodeList iterator which would be able to skip of these zero entries. - we could attempt to store in the TraceContext a Ptr<Node> rather than a node index, hence making the whole index problem go away. - ... However, every implementation option I looked is somewhat non-trivial to retrofit within the current codebase so, I am a bit worried that this is going to be really painful to do and, my next question is: what is the expected output ? I can imagine lots of use-cases where, indeed, being able to create and destroy nodes during the simulation could be useful. The crux of the problem is that supporting properly such a scenario requires much more work than just dealing with node ids and the NodeList. i.e., as soon as you start doing partial destructions of the simulation topology, you need to make sure that the global system stays in a valid state. The current codebase was really designed to _not_ support partial tearoffs so, if you try to do it, you will have to work around a lot of design bugs, and you will have to put together a lot of adhoc hacks for your specific scenario. So, to summarize, to go forward with this bug, I think that we need to have a very clear plan of how we can achieve partial destruction of a network topology in such a way that the system stays in a coherent state after the partial destruction. Examples of problematic use-cases: - global routing data structures need updates - what are the semantics of destroying a NetDevice connected to a Channel with multiple other NetDevices ? - same question for a pair of NetDevice and a single Channel.
I would like to mark this bug as WONTFIX.
I guess I can live with it as long as there is a way to "reset" a terminal, i.e. destroy all applications and sockets, so that the terminal can be reused later on... it's not nice but doable...
Sockets can definitely be closed. For applications, we would need to add Node::RemoveApplication. You could also just stop the application and not remove it from the node: it does not really do much harm to leave a stopped application around.