Open snickell opened 1 month ago
This may still have issues with pandas 🐼: after the finalize, when the process exits, it segfaults after the at_exit handlers. I need to figure out how to debug this in lldb.
It might be necessary to unregister gc objects before calling Py_FinalizeEx
. These are destroyed automatically at process exit, but the (PyObject *) pointers were previously invalidated by Py_FinalizeEx, so the process segfaults at exit.
Initialized when pycall.so starts:
When PyCall.gcguard_table is destroyed by Ruby:
pycall_gcguard_register() registers weak-refs to Python objects, which call pycall_gcguard_delete()
when they are destroyed. It does not appear to be used, but I have documented it anyway to be careful.
Fixes #186
Currently: if you use PyCall from a "side thread" (="not the main thread), when you exit the process does not exit. See #186 for more information.
Using this PR, the "side thread" may manually call
PyCall.initialize
before it exits. Then the main thread will exit properly. Unfortunately, it is not possible to automatically callPyCall.initialize
in a side-thread, becauseat_exit
only runs on the main thread, and there is no handler for thread.on_exit.This PR:
PyCall.finalize()
, which calls Py_FinalizeEx()PyCall.finalize()
at_exit, if initialized on the main threadA secondary advantage of this PR: it cleans up python memory before exit, which might make it easier to use valgrind and other memory debugging tools.
Example using this PR:
Before this PR (=comment out PyCall.finalize), the process would never exit even after both threads exited.