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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
