[WIP] bpo-40533: Make PyObject.ob_refcnt atomic in subinterpreters#19958
[WIP] bpo-40533: Make PyObject.ob_refcnt atomic in subinterpreters#19958vstinner wants to merge 1 commit intopython:masterfrom vstinner:atomic_refcnt
Conversation
When Python is built with experimental isolated interpreters, declare PyObject.ob_refcnt and _dictkeysobject.dk_refcnt as atomic variables. Temporary workaround until subinterpreters stop sharing Python objects.
|
Based on the discussion at https://mail.python.org/archives/list/[email protected]/thread/2WHQBHFK7UQ7OYAJV5S2QCINODVVKGJY/#2WHQBHFK7UQ7OYAJV5S2QCINODVVKGJY, I think we should leave a |
Right, thanks. I converted this PR into a draft to ensure that nobody merges it by mistake. |
vstinner
changed the title
| #ifdef EXPERIMENTAL_ISOLATED_SUBINTERPRETERS | ||
| /* bpo-40533: Use an atomic variable for PyObject.ob_refcnt, to ensure that | ||
| Py_INCREF() and Py_DECREF() are safe when called in parallel, until | ||
| subinterpreters stop sharing Python objects. */ | ||
| _Atomic Py_ssize_t ob_refcnt; |
There was a problem hiding this comment.
Perhaps this is somewhat emphasized by the "experimental" part, but could we possibly make it a bit more crystal clear that this is only a temporary stopgap measure? I personally find that "until subinterpreters stop sharing Python objects" could be interpreted as a near indefinite amount of time; I'm not confident that most readers will go over the full context in the bpo issue and related discussions.
Normally, this wouldn't be a huge concern, but I think object.h is likely one of the most public-facing header files in CPython, so it seems important to communicate this as clearly as possible.
|
The current plan is to not share any object between two interpreters, so this PR is not needed. I close it. |
4 participants
When Python is built with experimental isolated interpreters, declare
PyObject.ob_refcnt and _dictkeysobject.dk_refcnt as atomic variables.
Temporary workaround until subinterpreters stop sharing Python
objects.
https://bugs.python.org/issue40533