[issue42039] Add gc.track and gc.untrack

2020-10-15 Thread Pablo Galindo Salgado
Pablo Galindo Salgado added the comment: > 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

[issue42039] Add gc.track and gc.untrack

2020-10-15 Thread Inada Naoki
Inada Naoki added the comment: > 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

[issue42039] Add gc.track and gc.untrack

2020-10-15 Thread Pablo Galindo Salgado
Pablo Galindo Salgado added the comment: 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 -- ___ Python tracker

[issue42039] Add gc.track and gc.untrack

2020-10-15 Thread Inada Naoki
Inada Naoki added the comment: and this: https://github.com/python/cpython/blob/b67cbbda3a022cec5e2ad929f0531162166e7c8d/Include/internal/pycore_object.h#L111-L113 -- ___ Python tracker

[issue42039] Add gc.track and gc.untrack

2020-10-15 Thread Inada Naoki
Inada Naoki added the comment: I meant this: https://github.com/python/cpython/blob/b67cbbda3a022cec5e2ad929f0531162166e7c8d/Include/internal/pycore_object.h#L75-L78 -- ___ Python tracker

[issue42039] Add gc.track and gc.untrack

2020-10-15 Thread Pablo Galindo Salgado
Pablo Galindo Salgado added the comment: 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

[issue42039] Add gc.track and gc.untrack

2020-10-14 Thread Inada Naoki
Inada Naoki added the comment: 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. -- nosy: +methane ___ Python tracker

[issue42039] Add gc.track and gc.untrack

2020-10-14 Thread Brandt Bucher
Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42039] Add gc.track and gc.untrack

2020-10-14 Thread Pablo Galindo Salgado
Change by Pablo Galindo Salgado : -- nosy: +tim.peters stage: patch review -> ___ Python tracker ___ ___ Python-bugs-list mailing

[issue42039] Add gc.track and gc.untrack

2020-10-14 Thread Pablo Galindo Salgado
Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +21669 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22699 ___ Python tracker

[issue42039] Add gc.track and gc.untrack

2020-10-14 Thread Pablo Galindo Salgado
New submission from Pablo Galindo Salgado : 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