[Python-Dev] PEP 556: Threaded garbage collection
Nick Coghlan
ncoghlan at gmail.com
Fri Sep 8 13:03:33 EDT 2017
More information about the Python-Dev mailing list
Fri Sep 8 13:03:33 EDT 2017
- Previous message (by thread): [Python-Dev] PEP 556: Threaded garbage collection
- Next message (by thread): [Python-Dev] PEP 556: Threaded garbage collection
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 8 September 2017 at 08:05, Antoine Pitrou <solipsis at pitrou.net> wrote: > > Hello, > > I've written a PEP by which you can tell the GC to run in a dedicated > thread. The goal is to solve reentrancy issues with finalizers: > https://www.python.org/dev/peps/pep-0556/ +1 from me for the general concept. (Minor naming idea: "inline" may be a clearer name for the current behaviour). One point that seems worth noting: even with cyclic GC moved out to a separate thread, __del__ methods and weakref callbacks triggered by a refcount going to zero will still be called inline in the current thread. Changing that would require a tweak to the semantics of Py_DECREF where if the GC was in threaded mode, instead of finalizing the object immediately, it would instead be placed on a FIFO queue where the GC thread would pick it up and then actually delete it. Cheers, Nick. > PS: I did not come up with the idea for this PEP while other people > were having nightmares. I dunno, debugging finalizer re-entrancy problems seems pretty nightmarish to me ;) -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message (by thread): [Python-Dev] PEP 556: Threaded garbage collection
- Next message (by thread): [Python-Dev] PEP 556: Threaded garbage collection
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list