> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
