Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Appropriately dispose of SMARTS at exit #378

Closed
4 tasks
Gamenot opened this issue Jan 4, 2021 · 2 comments · Fixed by #665
Closed
4 tasks

Appropriately dispose of SMARTS at exit #378

Gamenot opened this issue Jan 4, 2021 · 2 comments · Fixed by #665
Assignees

Comments

@Gamenot
Copy link
Collaborator

Gamenot commented Jan 4, 2021

Instances of the SMARTS class hold on to a lot of resources that do not get automatically cleaned up on exit.

AC:

  • Investigate to see if SMARTS instance can automatically close on exit
  • SMARTS instance is cleaned up when destroyed (e.x. SMARTS.destroy() is called from delete or atexit)
  • Introduce clear documentation to explain how to dispose of SMARTS instances appropriately.
  • Update all examples to follow the appropriate practice.
@Gamenot Gamenot added this to the Backlog milestone Jan 27, 2021
@junluo-huawei junluo-huawei changed the title Automate Dispose of SMARTS At Exit Appropriately dispose of SMARTS at exit Feb 17, 2021
@Gamenot Gamenot assigned Gamenot and JingfeiPeng and unassigned Gamenot Mar 8, 2021
@Gamenot
Copy link
Collaborator Author

Gamenot commented Mar 8, 2021

@sah-huawei Help Jeffer with this ticket.

@JingfeiPeng JingfeiPeng linked a pull request Mar 15, 2021 that will close this issue
JingfeiPeng added a commit that referenced this issue Mar 15, 2021
* can appropriately recreate and destroy smarts multiple times
* handled destroy in traffic_history_service
@JingfeiPeng
Copy link
Contributor

Closed with #665

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants