[Python-Dev] PEP 556: Threaded garbage collection

[Benjamin Peterson]

On Fri, Sep 8, 2017, at 12:24, Larry Hastings wrote:
> 
> 
> 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.)

Is the requirement that the construction and destruction be literally on
the same thread or merely non-concurrent? The GIL would provide the
latter.

>  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.

I'm only suggesting Python-level __del__ methods be run on the separate
thread not general deallocation work. I would those would be few and far
between.