summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorTim Peters <tim.peters@gmail.com>2004-10-10 02:47:33 (GMT)
committerTim Peters <tim.peters@gmail.com>2004-10-10 02:47:33 (GMT)
commit8470558a04d23ed01d1168c05781c016cb892b22 (patch)
tree2f078aa62fc1057fe1569ba829b79f9d3237dcfe
parent263091e38835bb96d06928ea56e4db73c1d2b7c1 (diff)
downloadcpython-8470558a04d23ed01d1168c05781c016cb892b22.zip
cpython-8470558a04d23ed01d1168c05781c016cb892b22.tar.gz
cpython-8470558a04d23ed01d1168c05781c016cb892b22.tar.bz2
PyInterpreterState_New(), PyThreadState_New(): use malloc/free directly.
This appears to finish repairs for SF bug 1041645. This is a critical bugfix.
-rw-r--r--Misc/NEWS10
-rw-r--r--Python/pystate.c20
2 files changed, 26 insertions, 4 deletions
diff --git a/Misc/NEWS b/Misc/NEWS
index e279dca..87c6f37 100644
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -136,6 +136,16 @@ Build
C API
-----
+- The C API calls ``PyInterpreterState_New()`` and ``PyThreadState_New()``
+ are two of the very few advertised as being safe to call without holding
+ the GIL. However, this wasn't true in a debug build, as bug 1041645
+ demonstrated. In a debug build, Python redirects the ``PyMem`` family
+ of calls to Python's small-object allocator, to get the benefit of
+ its extra debugging capabilities. But Python's small-object allocator
+ isn't threadsafe, relying on the GIL to avoid the expense of doing its
+ own locking. ``PyInterpreterState_New()`` and ``PyThreadState_New()``
+ call the platform ``malloc()`` directly now, regardless of build type.
+
- PyLong_AsUnsignedLong[Mask] now support int objects as well.
- SF patch #998993: ``PyUnicode_DecodeUTF8Stateful`` and
diff --git a/Python/pystate.c b/Python/pystate.c
index 703ce48..613f8cc 100644
--- a/Python/pystate.c
+++ b/Python/pystate.c
@@ -3,6 +3,16 @@
#include "Python.h"
+/* --------------------------------------------------------------------------
+CAUTION
+
+Always use malloc() and free() directly in this file. A number of these
+functions are advertised as safe to call when the GIL isn't held, and in
+a debug build Python redirects (e.g.) PyMem_NEW (etc) to Python's debugging
+obmalloc functions. Those aren't thread-safe (they rely on the GIL to avoid
+the expense of doing their own locking).
+-------------------------------------------------------------------------- */
+
#ifdef HAVE_DLOPEN
#ifdef HAVE_DLFCN_H
#include <dlfcn.h>
@@ -41,7 +51,8 @@ PyThreadFrameGetter _PyThreadState_GetFrame = NULL;
PyInterpreterState *
PyInterpreterState_New(void)
{
- PyInterpreterState *interp = PyMem_NEW(PyInterpreterState, 1);
+ PyInterpreterState *interp = (PyInterpreterState *)
+ malloc(sizeof(PyInterpreterState));
if (interp != NULL) {
HEAD_INIT();
@@ -119,7 +130,7 @@ PyInterpreterState_Delete(PyInterpreterState *interp)
Py_FatalError("PyInterpreterState_Delete: remaining threads");
*p = interp->next;
HEAD_UNLOCK();
- PyMem_DEL(interp);
+ free(interp);
}
@@ -133,7 +144,8 @@ threadstate_getframe(PyThreadState *self)
PyThreadState *
PyThreadState_New(PyInterpreterState *interp)
{
- PyThreadState *tstate = PyMem_NEW(PyThreadState, 1);
+ PyThreadState *tstate = (PyThreadState *)malloc(sizeof(PyThreadState));
+
if (_PyThreadState_GetFrame == NULL)
_PyThreadState_GetFrame = threadstate_getframe;
@@ -226,7 +238,7 @@ tstate_delete_common(PyThreadState *tstate)
}
*p = tstate->next;
HEAD_UNLOCK();
- PyMem_DEL(tstate);
+ free(tstate);
}