This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eric.snow
Recipients Decorater, eric.snow, ncoghlan, serhiy.storchaka, vstinner
Date 2017-11-21.15:46:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1511279174.05.0.213398074469.issue32096@psf.upfronthosting.co.za>
In-reply-to
Content
I see at least 3 ways to sort this out:

 1. partially revert the _PyRuntime change, sort of temporarily
   ("revert the change on memory allocators, and retry later to fix
   it, once other initializations issues are fixed", as suggested by
   Victor in the email thread)
 2. statically initialize the "raw" allocator with defaults, enough
   to make PyMem_RawMalloc() and PyMem_RawFree() work pre-init (this
   is what my PR does)
 3. use hard-coded defaults in PyMem_RawMalloc() and PyMem_RawFree()
   if the runtime has not been initialized yet

I considered implementing #3 instead, but wasn't sure about the performance impact.  It would add a pointer comparison to NULL and a branch on each PyMem_RawMalloc() and PyMem_RawFree() call.  I'm not convinved it would make much of a difference.  Furthermore, I consider #3 to be the simplest solution, both to implement and to maintain, so I'll probably try it out.
History
Date User Action Args
2017-11-21 15:46:14eric.snowsetrecipients: + eric.snow, ncoghlan, vstinner, serhiy.storchaka, Decorater
2017-11-21 15:46:14eric.snowsetmessageid: <1511279174.05.0.213398074469.issue32096@psf.upfronthosting.co.za>
2017-11-21 15:46:14eric.snowlinkissue32096 messages
2017-11-21 15:46:13eric.snowcreate