[Python-Dev] PEP 556: Threaded garbage collection (original) (raw)

Larry Hastings larry at hastings.org
Fri Sep 8 15:24:32 EDT 2017

On 09/08/2017 12:04 PM, Benjamin Peterson wrote:

- Why not run all (Python) finalizers on the thread and not just ones from cycles?

Two reasons:

  1. Because some code relies on the finalizer being called on the thread where the last reference is dropped. This is usually the same thread where the object was created. Some irritating third-party libraries make demands on callers, e.g. "you can only interact with / destroy X objects on your 'main thread'". This is often true of windowing / GUI libraries. (For example, I believe this was true of Direct3D, at least as of D3D8; it was also often true of Win32 USER objects.)
  2. Because there's so much work there. In the Gilectomy prototype, I originally called all finalizers on the "reference count manager commit thread", the thread that also committed increfs and decrefs. The thread immediately fell behind on its queue and never caught up. I changed the Gilectomy so objects needing finalization are passed back to the thread where the last decref happened, for finalization on that thread; this was pleasingly self-balancing.

Note that I turned off cyclic GC on the Gilectomy prototype a long time ago and haven't revisited it since. My very, very long-term plan for GC is to stop the world and run it from one thread. With the current system, that means all those finalizers would be run on the thread chosen to run the GC.

//arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170908/e243bc6e/attachment.html>

More information about the Python-Dev mailing list