[Python-Dev] PEP 556: Threaded garbage collection
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?
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev