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 sable
Recipients BreamoreBoy, flub, loewis, neologix, pitrou, sable, tim.peters
Date 2011-04-29.16:03:59
SpamBayes Score 5.761236e-11
Marked as misclassified No
Message-id <1304093042.03.0.680855314337.issue3526@psf.upfronthosting.co.za>
In-reply-to
Content
Yes, I was probably not clear:
When --with-dlmalloc is activated, PyMem_MALLOC/PyMem_Malloc will call dlmalloc, PyMem_REALLOC/PyMem_Realloc will call dlrealloc and PyMem_FREE/PyMem_Free will call dlfree.

While calls to malloc/free/realloc will use the platform implementation.

So I think there should not be any mix, since as it is mentioned in pymem.h, people should not mix PyMem_MALLOC/PyMem_FREE with malloc/free:

/* BEWARE:

   Each interface exports both functions and macros.  Extension modules should
   use the functions, to ensure binary compatibility across Python versions.
   Because the Python implementation is free to change internal details, and
   the macros may (or may not) expose details for speed, if you do use the
   macros you must recompile your extensions with each Python release.

   Never mix calls to PyMem_ with calls to the platform malloc/realloc/
   calloc/free.  For example, on Windows different DLLs may end up using
   different heaps, and if you use PyMem_Malloc you'll get the memory from the
   heap used by the Python DLL; it could be a disaster if you free()'ed that
   directly in your own extension.  Using PyMem_Free instead ensures Python
   can return the memory to the proper heap.  As another example, in
   PYMALLOC_DEBUG mode, Python wraps all calls to all PyMem_ and PyObject_
   memory functions in special debugging wrappers that add additional
   debugging info to dynamic memory blocks.  The system routines have no idea
   what to do with that stuff, and the Python wrappers have no idea what to do
   with raw blocks obtained directly by the system routines then.

   The GIL must be held when using these APIs.
*/
History
Date User Action Args
2011-04-29 16:04:02sablesetrecipients: + sable, tim.peters, loewis, pitrou, flub, neologix, BreamoreBoy
2011-04-29 16:04:02sablesetmessageid: <1304093042.03.0.680855314337.issue3526@psf.upfronthosting.co.za>
2011-04-29 16:04:00sablelinkissue3526 messages
2011-04-29 16:03:59sablecreate