Kitware
Python interpreter not de-initialized properly at program end
We're having an issue in VIAME with a process that uses Pytorch, which in turn uses the Python multiprocessing module. What we're seeing is that after the pipeline runner ends, some of the child processes from multiprocessing are being orphaned and inherited by the init process because they didn't terminate properly. This is especially problematic for us because these processes consume CUDA memory and have to be manually terminated to free the memory.
I did some reading and found this warning: "If the main process exits abruptly (e.g. because of an incoming signal), Python's multiprocessing sometimes fails to clean up its children. It's a known caveat, so if you're seeing any resource leaks after interrupting the interpreter, it probably means that this has just happened to you." This looks exactly like what we're seeing, and makes me think that it's happening because we're not properly de-initializing the Python interpreter at the end of the program.
If this is the case, the obvious solution is to de-initialize the Python interpreter, but I'm not sure how to go about this. It's easy enough in the pipeline runner, but what about third-party software (such as Vivia) that includes the Kwiver libraries and has embedded pipelines? They would need to know when to initiate this Kwiver cleanup.
Right now my idea is to put a pybind scoped_interpreter in a shared_ptr for automatic destruction. I'd like to hear what others think about how to do this.
The Kwiver plugin system has a register_factories() entry point for each plugin. Does it have something similar for de-initialization?