[issue44881] Consider integration of PyObject_GC_UnTrack() with the trashcan C API

Neil Schemenauer added the comment: Another small correction, _PyType_IS_GC() checks only the type flag (Py_TPFLAGS_HAVE_GC). _PyObject_IS_GC() checks both the type flag and calls tp_is_gc(), if it exists. tp_is_gc() is wart, IMHO, and it would be nice if we can kill it off so only the typ

[issue44881] Consider integration of PyObject_GC_UnTrack() with the trashcan C API

Neil Schemenauer added the comment: > I think in any case we should benchmark this because this will affect *all* > GC types if I understand correctly and the TS mechanism had shown slowdowns > before We definitely need to benchmark. I would guess that adding trashcan protection to all GC type

[issue44881] Consider integration of PyObject_GC_UnTrack() with the trashcan C API

Pablo Galindo Salgado added the comment: Thanks Neil for the thorough explanation! I think in any case we should benchmark this because this will affect *all* GC types if I understand correctly and the TS mechanism had shown slowdowns before -- __

[issue44881] Consider integration of PyObject_GC_UnTrack() with the trashcan C API

Neil Schemenauer added the comment: > The problem of PyObject_GC_UnTrack() is just the most visible effect of the > trashcan mecanism: tp_dealloc can be called twice, and this is *not* expected > by the tp_dealloc API. The fact that Py_TRASHCAN_BEGIN and Py_TRASHCAN_END can cause tp_dealloc to

[issue44881] Consider integration of PyObject_GC_UnTrack() with the trashcan C API

STINNER Victor added the comment: The problem of PyObject_GC_UnTrack() is just the most visible effect of the trashcan mecanism: tp_dealloc can be called twice, and this is *not* expected by the tp_dealloc API. Putting trashcan mecanism outside tp_dealloc can allow to make sure that tp_deal

[issue44881] Consider integration of PyObject_GC_UnTrack() with the trashcan C API

Neil Schemenauer added the comment: I wrote a proof-of-concept as bpo-44897. PR 27718 (this issue) might a slightly better performance but I like the other one better because it doesn't expose so much implementation detail to extension types. Either of them require careful review before me

[issue44881] Consider integration of PyObject_GC_UnTrack() with the trashcan C API

Neil Schemenauer added the comment: I was thinking about this more today and I think the better fix is to actually build the trashcan mechanism into _Py_Dealloc(). Requiring that types opt-in to the trashcan mechanism by using the trashcan macros is not ideal. First, the trashcan macros a

[issue44881] Consider integration of PyObject_GC_UnTrack() with the trashcan C API

STINNER Victor added the comment: > Now, any object that uses the trashcan *must* be a GC object. It would be nice to add an assertion in _PyTrash_begin(). -- ___ Python tracker

[issue44881] Consider integration of PyObject_GC_UnTrack() with the trashcan C API

Change by STINNER Victor : -- title: Consider integration of GC_UNTRACK with TRASHCAN -> Consider integration of PyObject_GC_UnTrack() with the trashcan C API ___ Python tracker _