This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author nascheme
Recipients nascheme, pablogsal
Date 2021-08-10.23:38:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1628638705.72.0.705451001049.issue44881@roundup.psfhosted.org>
In-reply-to
Content
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.
History
Date User Action Args
2021-08-10 23:38:25naschemesetrecipients: + nascheme, pablogsal
2021-08-10 23:38:25naschemesetmessageid: <1628638705.72.0.705451001049.issue44881@roundup.psfhosted.org>
2021-08-10 23:38:25naschemelinkissue44881 messages
2021-08-10 23:38:25naschemecreate