[Python-Dev] PEP 556: Threaded garbage collection

[Larry Hastings]

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>