Process to cleanly exit on KeyboardInterupt

[avylove]

When you have a utility that wraps gitpython, raising KeyboardInterupt with ctrl-c results in threads that aren't cleanly exited. Is there a process where a KeyboardInterupt can be handled with a clean exit?

I tried to see if I could list the threads and try to terminate them, but it seems the ctrl-c triggers the threads to shutdown before it gets to the exception block.

^CTraceback (most recent call last):
  File ".venv/bin/comma", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "comma/cli/__init__.py", line 181, in main
    Session(config, database)(options)
  File "comma/cli/__init__.py", line 146, in __call__
    getattr(self, options.subcommand)(options)
  File "comma/cli/__init__.py", line 100, in run
    Downstream(self.config, self.database, repo).monitor()
  File "comma/downstream/__init__.py", line 85, in monitor
    repo.fetch_remote_ref(
  File "comma/util/tracking.py", line 176, in fetch_remote_ref
    fetch_info = remote.fetch(remote_ref, depth=1, **kwargs)[-1]
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".venv/lib/python3.11/site-packages/git/remote.py", line 1015, in fetch
    res = self._get_fetch_info_from_stderr(proc, progress, kill_after_timeout=kill_after_timeout)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".venv/lib/python3.11/site-packages/git/remote.py", line 844, in _get_fetch_info_from_stderr
    handle_process_output(
  File ".venv/lib/python3.11/site-packages/git/cmd.py", line 182, in handle_process_output
    t.join(timeout=kill_after_timeout)
  File "/usr/lib64/python3.11/threading.py", line 1112, in join
    self._wait_for_tstate_lock()
  File "/usr/lib64/python3.11/threading.py", line 1132, in _wait_for_tstate_lock
    if lock.acquire(block, timeout):
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyboardInterrupt
Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedReader name=5> at interpreter shutdown, possibly due to daemon threads
Python runtime state: finalizing (tstate=0x00007fcb2e90dbf8)

Current thread 0x00007fcb2e986740 (most recent call first):
  File ".venv/lib/python3.11/site-packages/git/cmd.py", line 533 in _terminate
  File ".venv/lib/python3.11/site-packages/git/cmd.py", line 567 in __del__

Extension modules: pydantic.typing, pydantic.errors, pydantic.version, pydantic.utils, pydantic.class_validators, pydantic.config, pydantic.color, pydantic.datetime_parse, pydantic.validators, pydantic.networks, pydantic.types, pydantic.json, pydantic.error_wrappers, pydantic.fields, pydantic.parse, pydantic.schema, pydantic.main, pydantic.dataclasses, pydantic.annotated_types, pydantic.decorator, pydantic.env_settings, pydantic.tools, pydantic, _ruamel_yaml, approxidate._c, sqlalchemy.cimmutabledict, greenlet._greenlet, sqlalchemy.cprocessors, sqlalchemy.cresultproxy, rapidfuzz._feature_detector_cpp, rapidfuzz.distance._initialize_cpp, rapidfuzz.distance.metrics_cpp_avx2, rapidfuzz.fuzz_cpp_avx2, rapidfuzz.process_cpp_impl, rapidfuzz.utils_cpp, Levenshtein.levenshtein_cpp (total: 36)
Aborted (core dumped)

[Byron]

That's a general issue with all python programs that do IO while being interrupted.
However, installing a signal handler in the parent application should be able to deal with this gracefully. The idea is to change the program state when receiving a signal so that the application can shut down gracefully. GitPython does not support interruptions though, so long-running clones will have to be waited upon. Common ways to deal with this is to call os.abort() or sys.exit to exit anyway, possibly without any other exceptions particularly in the case of os.abort().