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

gh-124074: Add _Py_NewImmortalRef() function #124076

Closed
wants to merge 1 commit into from

Conversation

vstinner
Copy link
Member

@vstinner vstinner commented Sep 13, 2024

@vstinner
Copy link
Member Author

cc @encukou

Comment on lines +878 to +880
// Similar to Py_NewRef() but for immortal objects.
// obj must be immortal.
static inline PyObject* _Py_NewImmortalRef(PyObject *obj)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PEP 7:

Suggested change
// Similar to Py_NewRef() but for immortal objects.
// obj must be immortal.
static inline PyObject* _Py_NewImmortalRef(PyObject *obj)
// Similar to Py_NewRef() but for immortal objects.
// obj must be immortal.
static inline PyObject *
_Py_NewImmortalRef(PyObject *obj)

@encukou
Copy link
Member

encukou commented Sep 16, 2024

cc @encukou

If you ask me: I don't think this is useful without

  • broad agreement among the core devs that it should be used;
  • a checker (e.g. including these in the refcount total -- until all the calls are fixed it would need to be optional);
  • documentation (in Devguide or InternalDocs);
  • a DECREF equivalent.

@vstinner
Copy link
Member Author

vstinner commented Sep 16, 2024

a checker (e.g. including these in the refcount total -- until all the calls are fixed it would need to be optional);

Do you mean a tool which would fail if _Py_NewImmortalRef() is used to "INCREF" but Py_DECREF() (or _Py_DecRefImmortal()) would be omitted by mistake? It seems non trivial to implement checker in an efficient way.

@ZeroIntensity
Copy link
Member

ZeroIntensity commented Sep 16, 2024

For clarification: would _Py_NewImmortalRef only get used for immortal constants (things like Py_None, Py_True, Py_False), or try and retrofit it for other things that we happen to know are immortal (e.g., some interned strings)? If it's the former, then it should be relatively easy to write a checker for that.

@vstinner
Copy link
Member Author

It works on any immortal object: https://docs.python.org/dev/glossary.html#term-immortal

@encukou
Copy link
Member

encukou commented Sep 17, 2024

Do you mean a tool which would fail if _Py_NewImmortalRef() is used to "INCREF" but Py_DECREF() (or _Py_DecRefImmortal()) would be omitted by mistake? It seems non trivial to implement checker in an efficient way.

AFAIK, it would only need the existing _Py_IncRefTotal and _Py_DecRefTotal.

@vstinner
Copy link
Member Author

AFAIK, it would only need the existing _Py_IncRefTotal and _Py_DecRefTotal.

It's more complicated than that since Python/ceval.c now converts immortal objects to "stack ref" objects and it doesn't call DECREF on them on purpose. Maybe it's a lost battle and we should give up on doing Py_NewRef(Py_None), but just write Py_None.

@encukou
Copy link
Member

encukou commented Sep 17, 2024

It's more complicated than that since Python/ceval.c now converts immortal objects to "stack ref" objects and it doesn't call DECREF on them on purpose.

Yeah, it would need to start doing that DECREF, in debug builds. Otherwise, _Py_NewImmortalRef is no better than a comment.

@vstinner
Copy link
Member Author

I prefer to abandon this function at this point. I failed to update Py_INCREF(), Py_DECREF() and _Py_NewImmortalRef() to keep a consistent "total ref count" using _Py_INCREF_IncRefTotal(); and _Py_DECREF_DecRefTotal();.

@vstinner vstinner closed this Sep 17, 2024
@vstinner vstinner deleted the new_immortal_ref branch September 17, 2024 12:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants