Kristján Valur Jónsson added the comment: Keeping the GIL requirement is _very_ useful for PyMem_MALLOC et al. It allows applications to hook in their own monitoring code, accessible from python itself, without having to worry about conflicts with python. even if it were not for the GIL itself, PyMem_Malloc() may have all sorts of side effects.
Because of this, and to allow ourselves the flexibility to do all sorts of things inside PyMem_Malloc(), at CCP we added a parallel api, PyMem_MALLOC_RAW() etc. This api is guaranteed to delegate directly to the external allocator (malloc by default, or an embedding application's supplied allocastor) We have patched pythoncore in 2.7 in all places there were using malloc directly using the file attached to the defect. Notice how it can patch "malloc" in two different ways, using either regular malloc (in non-sensitive areas) and using the raw malloc (in sensitive areas.) e.g. thread.c contains the following lines in our branch: #include "Python.h" /* patch malloc/free with threadsafe python versions */ #define CCPMEM_PATCH_RAW #include "ccpmem_patch.h" ---------- Added file: http://bugs.python.org/file30581/ccpmem_patch.h _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18203> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
