[Python-Dev] Python initialization and embedded Python

Antoine Pitrou solipsis at pitrou.net
Thu Nov 23 05:16:25 EST 2017


On Thu, 23 Nov 2017 10:37:59 +0100
"M.-A. Lemburg" <mal at egenix.com> wrote:
> On 18.11.2017 01:01, Victor Stinner wrote:
> > Hi,
> > 
> > The CPython internals evolved during Python 3.7 cycle. I would like to
> > know if we broke the C API or not.
> > 
> > Nick Coghlan and Eric Snow are working on cleaning up the Python
> > initialization with the "on going" PEP 432:
> > https://www.python.org/dev/peps/pep-0432/
> > 
> > Many global variables used by the "Python runtime" were move to a new
> > single "_PyRuntime" variable (big structure made of sub-structures).
> > See Include/internal/pystate.h.
> > 
> > A side effect of moving variables from random files into header files
> > is that it's not more possible to fully initialize _PyRuntime at
> > "compilation time". For example, previously, it was possible to refer
> > to local C function (functions declared with "static", so only visible
> > in the current file). Now a new "initialization function" is required
> > to must be called.
> > 
> > In short, it means that using the "Python runtime" before it's
> > initialized by _PyRuntime_Initialize() is now likely to crash. For
> > example, calling PyMem_RawMalloc(), before calling
> > _PyRuntime_Initialize(), now calls the function NULL: dereference a
> > NULL pointer, and so immediately crash with a segmentation fault.  
> 
> To prevent a complete crash, would it be possible to initialize
> the struct entries to a generic function (or set of such functions
> with the right signatures), which then issue a message to stderr
> hinting to the missing call to _PyRuntime_Initialize()
> before terminating ?

+1.  This sounds like a good idea.

Regards

Antoine.




More information about the Python-Dev mailing list