Attention is currently required from: fixeria, laforge, pespin.
Patch set 4:Code-Review -2
5 comments:
Patchset:
I disagree with this patch, because you are mixing the "there is a free() call in the source" with "it is not freed anywhere". In osmo-msc, you need to grep for osmo_fsm_inst_term instead.
The memory management in osmo-msc is far from trivial, and it took a good amount of time to make sure that each object tears down dependent objects, while not causing double frees or leaks. The decision that each FSM instance takes care of its own priv object is PIVOTAL to this design.
So in short, you are starting at a big refactoring, which I disagree with.
Commit Message:
Swap the talloc tree parentship to have the fi be a child of the object,
which simplifies tear down triggered by FSM cleanup.
It's logical, but it has drawbacks, like not being able to quickly figuring out where the object is […]
you may find that, but you have not convinced me yet.
All FSMs that I implement have a priv object as the child of the fsm inst, hence this is the pattern i expect to see. It also accurately reflects that the FSM instance is responsible for deallocation.
Could you describe an objective drawback, thx
File src/libmsc/ran_peer.c:
Patch Set #4, Line 551: .cleanup = ran_peer_fsm_cleanup,
The fsm.cleanup function is an integral part of osmo-msc's object management, to handle corner cases gracefully. I am pretty sure that ran_peer needs a cleanup function to be resilient against failures.
Beyond this, I subjectively prefer that we stick to the pattern that is used in the other FSM instances in osmo-msc.
Patch Set #4, Line 81: void ran_peer_free(struct ran_peer *rp)
AFAIR the idea is to instead call osmo_fsm_inst_term()
Patch Set #4, Line 129: static void ran_peer_discard_all_conns(struct ran_peer *rp)
separate patch
To view, visit change 40632. To unsubscribe, or for help writing mail filters, visit settings.