Python module not finalized or too late / Memory leak

[Enyium]

• OS: Windows 11 Home 25H2
• Talon version: 0.4.0 public

First: Please guarantee that an old Python module object is always quickly garbage-collected. I.e., if you're not already doing this, please call gc.collect() in the context of a script reload. This can, e.g., be important to abort an old thread that the new Python module restarts. See also the todo at the start of my windows_toolkit_talon's reload_resilience.py (fixed commit). (You can read it with wrapped lines by using GitHub's "Raw" button.)

---

Please consider the two todos at the start of windows_toolkit_talon's /pymod_termination/index.py (fixed commit) that are directed at you, the Talon author.

---

The "private notes" of the first todo refer to these reproduction steps:

• Create bug.talon:

  debug set event: user.dbg_set_event()

  If needed, this allows you to differentiate old module objects.

• Create bug.py:

  Click to view.

  import sys
  import threading
  import weakref
  
  import talon
  
  _mod = talon.Module()
  _event = threading.Event()
  
  @_mod.action
  def dbg_set_event():
      """..."""
      _event.set()
  
  _pymod_name = __name__
  weakref.finalize(
      sys.modules[_pymod_name],
      lambda name=_pymod_name: print(f"Python module `{name}` finalized. Event set: {_event.is_set()}"),
  )
  
  _pymod_dict_representative = frozenset()  # Something weakly referenceable.
  weakref.finalize(
      _pymod_dict_representative,
      lambda name=_pymod_name: print(f"`__dict__` of module `{name}` finalized."),
  )

  Note that module finalizers are officially supported as per the bottom of this page.

• On the first execution, nothing is printed. — Correct, because there was no old module to be finalized.

• On the second execution (by changing the file), something is printed. — Correct, because the module from the first execution was finalized.

• Do any number of reloads with the use or omission of the voice command that calls event.set() to get a feeling of what's to be expected.

• Bug: On any bug.py-related file-remove action ([-] in log)—also by moving or renaming bug.py—the module isn't finalized. Only when a file-add action ([+] in log) for the same file path occurs (even with a zero-length file) does the tardy finalizer run. (When moving the file into and out of a subdirectory, this leads to the finalizers lagging one file-move step behind.)

---

The memory leak the second todo talks about has to do with the fact that a Python module object's __dict__ is also held by module globals like, e.g., functions and indirectly methods, which reference it in their respective __globals__ attributes. This creates a reference cycle that keeps the module __dict__ (not the module object) of every module version along the track of reloads alive. The above bug.py should demonstrate that `__dict__` of module `….bug` finalized. is never printed, even when running gc.collect().

[lunixbochs]

Reloading threaded code is intentionally not supported. It cannot be made safe unless I put all user code in a separate scripting host process which Talon can hard restart.

Module finalizers are similar, they're intentionally not provided in the top-level module form. It's unfortunately too easy for the user code to mess it up, which would still require a Talon restart to fix. There's also not a clean sequence point between the old module unloading and the new module loading, because among other things Talon is robust to critical errors during module loading.

Based on this and other recent issues you've filed, you might be at a point soon where some of your plugin may behave better in a subprocess communicating over stdio. At that point it's also easier to isolate the behavior of your plugin and Talon's behavior from each other.

[Enyium]

your plugin may behave better in a subprocess communicating over stdio.

As I understand, a subprocess wouldn't have UIAccess privileges, which is bad. It also seems more complicated to me - needing a communication protocol and such.

Reloading threaded code is intentionally not supported. It cannot be made safe

Talon's behavior in the context of reloads just needs to be clean and defined enough, so that one can work (develop) with it, which also concerns repo updates where Git changes files. Then, the user is responsible for safety, as they already are when, e.g., working with cron jobs that access the same data as Talon actions or event handlers.

This would be better than the broken state, even if not providing easy APIs or solving the memory leak (which also affects non-threaded code). (Not solving the memory leak using module dict teardown would even be better for my threaded code if you wouldn't also implement teardown deferral as my /pymod_termination/index.py does.)

Wouldn't it be quite a passable solution to (1) not be too broken in Talon, so basic necessities for advanced use cases in the reload context are met, and (2) let a user repo provide support for solving the memory leak through module dict teardown and an easier API for reload-related callbacks?

There's also not a clean sequence point between the old module unloading and the new module loading

It would be okay (and useful for reload resilience logic, i.e., transferring data between reloads) when the old modules of a reload chain (including single-file reloads) were garbage-collected after the new ones ran. The most important thing is well-defined, dependable behavior and triggering garbage collection.