> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 01, 2007 20:46
> But then you would substantially change the memory access behavior of
> the
> program in a debug build, that is, more than it is already changed by
> the
> fact that you have cha
On 5/1/07, Tim Peters <[EMAIL PROTECTED]> wrote:
[Neal Norwitz]
>> 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
Shoul
[Neal Norwitz]
>> 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
Shouldn't do that.
[Brett Cannon]
> The PyMem_MALLOC cal
Kristján> I'd suggest to keep the debug functions as a thin layer on top
Kristján> of malloc to do basic testing.
But then you would substantially change the memory access behavior of the
program in a debug build, that is, more than it is already changed by the
fact that you have change
> 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.
Neal Norwitz gmail.com> writes:
>
> Can you call PyMem_FREE() without the GIL held? I couldn't find it
> documented either way.
Nope. See comments at the top of Python/pystate.c.
Cheers,
mwh
___
Python-Dev mailing list
Python-Dev@python.org
http:/
> 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 fu
On 5/1/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
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 creat
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
Can you call PyMem_FREE() without the GIL held? I couldn't find it
documented either way
