-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
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
gh-111926: Update _weakref to be threadsafe in --disable-gil build #112189
Conversation
corona10
commented
Nov 17, 2023
•
edited by bedevere-app
bot
Loading
edited by bedevere-app
bot
- Issue: Make weakref thread-safe without the GIL #111926
73233d3
to
c929bc0
Compare
I am going to work on |
There was some misunderstanding with my PR, I will re-send a patch for this :) |
@colesbury Hmm, I am not sure this was what you intended from #111926. IIUC, There might be two kinds of task that should be done
Please let me know if there is my misunderstanding. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good, other than the issue I mention below.
We will want to make both the module-level code (like this) and the operations on the weakref object thread-safe. I think it makes sense to split them up as separate PRs as you are doing.
Regarding Argument Clinic: maybe the @critical_section
directive should take an optional argument specifying which parameter name to lock. For now, I think writing the critical sections manually is fine.
The tricky bit will be making _PyWeakref_GET_REF
thread-safe because the lock is in the pointed-to object (ref->wr_object
), but that might change or even get deallocated. I think that will need an operation _Py_TryXFetchRef
from nogil-3.12
that isn't upstreamed yet. It may be worth doing the other bits and leaving _PyWeakref_GET_REF
for last