@Carreau You mentioned here that this PR cleans the history manager threads at garbage collection.
Would it be possible to have a more explicit and deterministic way of doing so?

Not without a major refactor and breaking a lot of APIs. Basically you would need InteractiveShell itself to be a contextmanager.

There are a number of other things that should be context managers. Some objects are doing crazy things like having reset() methods instead of having consumer just delete the current and create a new one – which made sens as a resource consumption 10 years ago, but not now anymore.

In conftest.py you can set HistorySavingThread's class attribute _max_inst to an integer and it will prevent creating more that that number of instances, so you can track the leaking ones.

See how I'm doing it in this PR, and the fixture I use to temporarily increase the number of HistoryManager for specific tests.

I think doing cleanup at garbage collection is very brittle because the object can only be garbage collected if there is no reference to it anymore, which is out of control.
I am not necessarily talking about using context managers, but at least providing a method that stops the thread, which would not be a breaking change.

There are already methods that stop the thread, you can already call history_manager.save_thread.stop(). Really there should be finalizers that should:

• be explicitly called in a context manager at best
• otherwise in a .destroy() or similar method
• if not, called at gc, but emit a ResourceWarning
• if not called at atexit (and also emit a resource warning)

finalizer will make sure those get called at most once, or be no-op, but still requires a lot of refactor and tracking.

Like right now, closing the thread while there are still live instance of history manager meas that we likely have a bug. So yes I agree with you, but it will need some manpower to make sure the code is sound (right now it definitely isn't), and detecting leaks will help us making it sound.