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 quite
similar to the concepts behind the pthread_once API (just with the lifecycle
tied to Py_Initialize/Py_Finalize rather than the C level process), and it's
the "initialise-on-first-use" behaviour that's significant here, moreso than
the fact that the typical storage target is a static variable.
As far as the linked list goes, the nice aspect of Victor's approach is that it
doesn't need to do any additional runtime memory allocations - all the storage
involved is still statically allocated in the modules that initialise the
values, there are just some extra pointer assignments to link everything
together (with the GIL protecting against race conditions).
However, the user visible ".obj" indirection could still be avoided at the cost
of an additional pointer per entry:
typedef struct _Py_OnceVar {
struct _Py_OnceVar *next;
PyObject **obj_ref;
} _Py_OnceVar;
#define _Py_ONCE_VAR(var_decl, var) \
var_decl var = NULL;
static _Py_OnceVar var ## _once_meta = {.next = NULL, .obj_ref =
(PyObject **) &var}
Intended declaration:
_Py_ONCE_VAR(static PyObject *, array_reconstructor);
_Py_ONCE_VAR_INIT would similarly be adjusted to assign the supplied value to
"var", while also setting "var_once_meta.next" to hook the value into the
linked list.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue29881>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
