[M.-A. Lemburg, on PyMem_xxx still using malloc/free even when pymalloc is enabled] > Depends on how you define PyMem_* ... I could have guessed that <wink>. > If you are saying that these macros/functions are only intended to > allocate memory blocks which Python will use, then it's probably OK to > let pymalloc handle these as well. > > If, for some reason, you intend to share the memory > with some other process/DLL/whatever, then I'm not > sure if this continues to work with pymalloc -- could > be that the platform's malloc() uses flags/locks etc. > to manage sharing. Just a thought, probably just FUD. > > ALAS, the only way to find out, is to try it. It's not entirely FUD. At least on Windows, you can get into a state where using memory APIs "from the same family" can nevertheless end up using different heaps, and then passing addresses around is a nightmare when one DLL tries to free memory obtained in a different DLL. As a uniform way to spell "use the Python DLL's view of what 'the heap' is to allocate and free", PyMem_XXX serve a real purpose there. But extensions currently mix, e.g., PyMem_Malloc() with free() too.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4