> I believe the GIL does not need to be held, but obviously Tim or someone > with more memory experience should step in to say definitively. > > If you look at Include/pymem.h, PyMem_FREE gets defined as PyObject_FREE > in a debug build. PyObject_Free is defined at _PyObject_DebugFree. > That function checks that the memory has not been written with the debug > bit pattern and then calls PyObject_Free. That call just sticks the > memory back into pymalloc's memory pool which is implemented without > using any Python objects. > > In other words no Python objects are used in pymalloc (to my knowledge) This is also what I found. > and thus is safe to use without the GIL. but I got to a different conclusion. If it really goes through the pymalloc pool (obmalloc), then it must hold the GIL while doing so. obmalloc itself is not thread-safe, and relies on the GIL for thread-safety. In release mode, PyMEM_FREE goes directly to free, which is thread-safe. Regards, Martin
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