[issue44881] Consider integration of GC_UNTRACK with TRASHCAN

[Neil Schemenauer]

Neil Schemenauer <nas-python at arctrix.com> added the comment:

Since C99 is now allowed, perhaps we should suggest that declarations go after Py_TRASHCAN_BEGIN, e.g.

	mytype_dealloc(mytype *p)
	{
	    Py_TRASHCAN_BEGIN(p, mytype_dealloc)
	    ... declarations go here ...
	    ... The body of the deallocator goes here, including all calls ...
	    ... to Py_DECREF on contained objects.                         ...
	    Py_TRASHCAN_END                // there should be no code after this
	}

The only dealloc method that doesn't fit this pattern is subtype_dealloc() and that's because the object might not be a GC object.

Given the pattern, it occurs to me that that _Py_Dealloc() could do the trashcan begin/end work.  However, the authors of the dealloc methods would have to realize the special rules of the trashcan (e.g. no returns from the dealloc method body).  Also, there would be some overhead added to _Py_Dealloc() to check if the trashcan is supported.  E.g. checking a type flag.

Another idea would be to add a new slot for the method, e.g. tp_dealloc_trash.  Then, _Py_Dealloc() could check if it exists and if so do the trashcan begin/end dance around it.  That would still add some overhead to _Py_Dealloc() so I think the current macros are the best approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44881>
_______________________________________