Repository navigation
Improve and decide on shutdown handling #21
Description
Shutting down has lingering object cleanup issues. Investigate and improve shutdown logic. This may include using "post to the executor" logic instead of directly calling state change callbacks.
Activity
cliffg-softwarelibre commentedon Jun 4, 2019
Significant work has gone into shutdown logic improvement and is merged the week of June 3rd. However, there is still additional testing needed and design decisions to be made related to shutdown, so this issue remains open. Specifically, it is still to be decided whether all resources can and should be cleaned up in various destructors, or whether calling "stop" on a net_entity is required for graceful shutdown.
cliffg-softwarelibre commentedon Jul 6, 2019
All known internal shutdown sequencing issues have been addressed (there may still be undiscovered problems). However, there is an API / usage question still unresolved:
stopon anet_entity, or can we callstopin a destructor (which destructor and where is still TBD). Putting non-trivial code in a destructor can cause many different kinds of problems, but it's also questionable whether we should always require apps to callstop.[-]Improve internal shutdown handling[/-][+]Improve and decide on shutdown handling[/+]n-deutsch commentedon Nov 12, 2019
Going to investigate this while I'm waiting for PR #40 to get merged in
cliffg-softwarelibre commentedon Nov 19, 2019
A related possible change (and if needed we can create a separate issue): Chops Net IP uses std::make_shared consistently. In general, this is a "good thing". However, we may be the exception to the rule. Arne Metz has a good blog post:
https://arne-mertz.de/2018/09/make_shared-vs-the-normal-shared_ptr-constructor/
Part of this investigation should be changing the std::make_shared to new in appropriate places (i.e. for the shared pointers that will have associated weak pointers to them) to see how this affects shutdown and memory cleanup.