(original) (raw)
On 5/1/07, Neal Norwitz <nnorwitz@gmail.com> wrote:
The PyMem\_MALLOC call that creates 'mode' is also called without explicitly holding the GIL.
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) and thus is safe to use without the GIL.
-Brett
In rev 54982 (the first time this crash was seen), I see something
which might create a problem. In python/trunk/Modules/posixmodule.c
(near line 6300):
+ PyMem_FREE(mode);
Py_END_ALLOW_THREADS
The PyMem\_MALLOC call that creates 'mode' is also called without explicitly holding the GIL.
Can you call PyMem\_FREE() without the GIL held? I couldn't find it
documented either way.
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) and thus is safe to use without the GIL.
-Brett