Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Refcount mess in mvAddCallback() and mvRunCallback() #2282

Open
wants to merge 29 commits into
base: master
Choose a base branch
from

Conversation

bzczb
Copy link

@bzczb bzczb commented Feb 12, 2024

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 take mvCallbackJob&&.

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() against PyDict_SetItem() etc.

mvAppItem is now enable_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 parent mvAppItem.

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, every mvAppItem destruction has taken place in a thread which already has the GIL.

Rename mvAddCallback() -> mvAddCallbackJob(), mvRunCallback() -> mvRunCallbackJob().
Moved the burden of the overloading to mvCallbackWithData, it's cleaner.

(cherry picked from commit 16b4bfe)
@v-ein
Copy link
Contributor

v-ein commented Feb 12, 2024

Ouch. That's what happens when you don't have time to publish your fix: another person duplicates the job you've already done :(.

Will try to review this one, but it will have to wait for quite long (let's say a month).

@bzczb
Copy link
Author

bzczb commented Feb 12, 2024

Ouch. That's what happens when you don't have time to publish your fix: another person duplicates the job you've already done :(.

Will try to review this one, but it will have to wait for quite long (let's say a month).

Sorry to bogart in... but this is a tricky bug, so it's good to fix it as many times as possible

Drag and drop still crashes in the demo.

(cherry picked from commit b3d6ad0)
…bject.

This may be a bit slower, but it makes resource management much easier.
Drag and drop doesn't crash anymore.

(cherry picked from commit 3e789c7)
(cherry picked from commit afad663)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Refcount mess in mvAddCallback() and mvRunCallback()
2 participants