classification
Title: Add gc.track and gc.untrack
Type: Stage: resolved
Components: Interpreter Core Versions: Python 3.10
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: pablogsal Nosy List: brandtbucher, methane, pablogsal, tim.peters
Priority: normal Keywords: patch

Created on 2020-10-14 18:31 by pablogsal, last changed 2020-10-15 10:38 by pablogsal. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 22699 closed pablogsal, 2020-10-14 18:33
Messages (8)
msg378645 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2020-10-14 18:31
We have C-API calls to track and untrack objects. Having similar calls in Python can be usefull to selectively deactivate the garbage collector for some objects for performance, debugging or testing purposes. For instance, in https://bugs.python.org/issue41984 this could have been very usefull
msg378660 - (view) Author: Inada Naoki (methane) * (Python committer) Date: 2020-10-15 03:29
There are many code that an object is tracked/untracked. This API can cause fatal error too easily.
I think this API should be exposed only in _testcapi.
msg378668 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2020-10-15 09:40
You mean because we need to modify _gc_prev and they may be in an inconsistent state? I may be missing something, but the only tricky moment is if someone calls this from a finalizer and in that case we have already constructed the reachable and unreachable sets. Or are you referring to other possible crashes?
msg378669 - (view) Author: Inada Naoki (methane) * (Python committer) Date: 2020-10-15 09:50
I meant this: https://github.com/python/cpython/blob/b67cbbda3a022cec5e2ad929f0531162166e7c8d/Include/internal/pycore_object.h#L75-L78
msg378670 - (view) Author: Inada Naoki (methane) * (Python committer) Date: 2020-10-15 09:50
and this: https://github.com/python/cpython/blob/b67cbbda3a022cec5e2ad929f0531162166e7c8d/Include/internal/pycore_object.h#L111-L113
msg378671 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2020-10-15 10:04
In my implementation, there is guards that do early return in those cases and there are tests that check that indeed we don't crash of that happens when calling the exposed functions
msg378672 - (view) Author: Inada Naoki (methane) * (Python committer) Date: 2020-10-15 10:27
> In my implementation, there is guards that do early return in those cases and there are tests that check that indeed we don't crash of that happens when calling the exposed functions

The guard doesn't help much. _PyObject_GC_UNTRACK() is called from many object tp_dealloc().
After user call `gc.untrack(obj)`, when the obj is deallocated, assertion error happens.
msg378673 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2020-10-15 10:38
> The guard doesn't help much. _PyObject_GC_UNTRACK() is called from many object tp_dealloc().
After user call `gc.untrack(obj)`, when the obj is deallocated, assertion error happens.

Oh, actually that is a very good point. Although we could argue if the check is super useful or not, I agree that as things are currently is not a good idea to expose these functions. I will close the issue.

Thanks a lot for pointing that out, Inada-san.
History
Date User Action Args
2020-10-15 10:38:56pablogsalsetstatus: open -> closed
resolution: rejected
messages: + msg378673

stage: resolved
2020-10-15 10:27:33methanesetmessages: + msg378672
2020-10-15 10:04:53pablogsalsetmessages: + msg378671
2020-10-15 09:50:50methanesetmessages: + msg378670
2020-10-15 09:50:14methanesetmessages: + msg378669
2020-10-15 09:40:32pablogsalsetmessages: + msg378668
2020-10-15 03:29:18methanesetnosy: + methane
messages: + msg378660
2020-10-14 18:46:10brandtbuchersetnosy: + brandtbucher
2020-10-14 18:33:45pablogsalsetnosy: + tim.peters

stage: patch review -> (no value)
2020-10-14 18:33:38pablogsalsetkeywords: + patch
stage: patch review
pull_requests: + pull_request21669
2020-10-14 18:31:23pablogsalcreate