-
-
Notifications
You must be signed in to change notification settings - Fork 954
-
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)
Beta Was this translation helpful? Give feedback.
All reactions
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().
Replies: 1 comment
-
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().
Beta Was this translation helpful? Give feedback.