[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

STINNER Victor added the comment: About _PY_ONCEVAR_INIT() vs _Py_IDENTIFIER. Using _Py_IDENTIFIER works well if you have an API accepting directly a _Py_IDENTIFIER*. If you call functions requesting a PyObject*, you need to call _PyUnicode_FromId() and test for failure. If you start by

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

STINNER Victor added the comment: 3rd round of the API: static PyObject *assertion_error = NULL; ... if (_PY_ONCEVAR_INIT(assertion_error, PyUnicode_InternFromString("AssertionError"))) { return 0; } ... (Not the best example,

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

Serhiy Storchaka added the comment: I think we can get rid of _Py_ONCEVAR(). Just keep current declarations. _PY_ONCEVAR_INIT() can work even with non-static global variables. It could work even with non-PyObject pointers. -- ___ Python tracker

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

STINNER Victor added the comment: About the pull request: to be clear, I know that some modified local variables should use _Py_IDENTIFIER() rather than _Py_ONCEVAR(), but I chose to use _Py_ONCEVAR() just to give examples of the API. -- ___ Python

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

STINNER Victor added the comment: > * do we ever declare non-statics this way? (OTOH, if we do, this could be an > opportunity to hide them behind read-only accessor functions) > * do we ever declare more specific types than PyObject * this way? (OTOH, if > that's the uncommon case, requiring

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

Nick Coghlan added the comment: Passing var_decl was based on not knowing the answer to two questions: * do we ever declare non-statics this way? (OTOH, if we do, this could be an opportunity to hide them behind read-only accessor functions) * do we ever declare more specific types than

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

Serhiy Storchaka added the comment: The new API rather combines pthread_once() and pthread_cleanup_push(). -- ___ Python tracker ___

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

Serhiy Storchaka added the comment: > "use gc_next/gc_refs for managing a linked list" Forgot about this idea. Not all objects have the GC header. But if they have it they could be removed from the GC list and added in the separate list since in any case the garbage collector shouldn't

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

STINNER Victor added the comment: I wrote a new different API: https://github.com/python/cpython/pull/780 New C API for variables only initialized once to be able to clear them at exit: New macro _Py_ONCEVAR(var) to declare a variable New macro _PY_ONCEVAR_INIT(var, expr) to initialize

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

Changes by STINNER Victor : -- pull_requests: +684 ___ Python tracker ___ ___

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

Serhiy Storchaka added the comment: My apologies Victor. It seems that the browser on my netbook shown only the part of changes and I seen only the change in array_array___reduce_ex__(). I like Nick's idea for hiding the indirection, but passing var_decl doesn't look having much sense to me.

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

STINNER Victor added the comment: Serhiy: "use gc_next/gc_refs for managing a linked list" I'm not sure that I understand your idea. These fields are already used internally by the garbage collector. If I modify one of these fields, it would corrupt the GC, no? Serhiy: "You can use a dynamic

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

STINNER Victor added the comment: #define _Py_ONCE_VAR(var_decl, var) \ var_decl var = NULL; static _Py_OnceVar var ## _once_meta = {.next = NULL, .obj_ref = (PyObject **) } Yeah, I had a similar idea, but I fear that it will increase the usage of the C stack memory. See the

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

STINNER Victor added the comment: Serhiy: "The patch contains an example of using _Py_STATICVAR(). But it doesn't use _PY_STATICVAR_INIT()." I'm not sure that I understand your comment. All modified code use _Py_STATICVAR() to declare the declare. All modified code use _PY_STATICVAR_INIT()

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

Nick Coghlan added the comment: I like this idea in principle, and suspect it may be helpful in the implementation of the new thread-specific-storage API proposed in PEP 539 (also see http://bugs.python.org/issue25658 ). How would you feel about calling it _Py_ONCE_VAR? The use case here is

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

Serhiy Storchaka added the comment: The patch contains an example of using _Py_STATICVAR(). But it doesn't use _PY_STATICVAR_INIT(). _PY_STATICVAR_INIT() can be used if extract the code of getting _array_reconstructor into separate function. I like the idea in general, but I want to see more

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

Changes by STINNER Victor : -- nosy: +ncoghlan ___ Python tracker ___ ___

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

STINNER Victor added the comment: The purpose of the issue is to fix memory leaks like issue #21387 (this one is not the best example since it seems like the leak doesn't come from a static variable.) -- ___ Python tracker

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

Serhiy Storchaka added the comment: The problem with existing static variables are that they are not properly cleared. When the Python interpreter is finalized and reinitialized they can contain invalid references. This patch fixes this issue. > * It requires to write "var.obj" instead of

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

Changes by STINNER Victor : -- pull_requests: +677 ___ Python tracker ___ ___

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

Changes by STINNER Victor : -- nosy: +eric.snow, serhiy.storchaka ___ Python tracker ___

[issue29881] Add a new private API for "static C variables" (_PyStaticVar) to clear them at exit

New submission from STINNER Victor: When I read Serhiy Storshaka's idea in issue #29878, it recalled me an old idea of writing a generalization of the _Py_IDENTIFIER() API. _Py_IDENTIFIER is an API to initialize a static string variable once. The _Py_Identifier structure has a "next" field to