fix: Refcount mess in mvAddCallback() and mvRunCallback() #2282
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR ought to be ignored until #2275 is merged and I've rebased this, there are a few complicated conflicts
name: Pull Request
about: Create a pull request to help us improve
title: 'Refcount mess in mvAddCallback() and mvRunCallback()'
assignees: '@hoffstadt @Pcothren @v-ein'
closes #2036
Description:
mvCallbackJob
is now an RAII struct that handles references to Python objects.Rename
mvAddCallback()
->mvAddCallbackJob()
,mvRunCallback()
->mvRunCallbackJob()
. Both of those functions only takemvCallbackJob&&
.mvCallbackJob
has a lot of overloads to make constructing it concise in different situations, and takes explicit flags for the borrow semantics.Using RAII structs, all the XINCREF and XDECREF can be worry-free, though you still have to watch out for
PyList_SetItem()
againstPyDict_SetItem()
etc.mvAppItem
is nowenable_shared_from_this
, which makes managing lifecycle of callbacks and callback data a lot easier. Make smart pointers to callbacks using the lifecycle of their parentmvAppItem
.Concerning Areas:
I hope I caught the ones which actually need to have
appData
borrowed, I did a broad search for those functions, but it's best to have that double checked.One must verify that neither manual callback management nor automatic callback management are broken.
Removed GIL locking from the destructor of
mvAppItem
. So far in my testing since those changes, everymvAppItem
destruction has taken place in a thread which already has the GIL.