diff options
author | Tim Peters <tim.peters@gmail.com> | 2004-10-10 02:47:33 (GMT) |
---|---|---|
committer | Tim Peters <tim.peters@gmail.com> | 2004-10-10 02:47:33 (GMT) |
commit | 8470558a04d23ed01d1168c05781c016cb892b22 (patch) | |
tree | 2f078aa62fc1057fe1569ba829b79f9d3237dcfe /Misc | |
parent | 263091e38835bb96d06928ea56e4db73c1d2b7c1 (diff) | |
download | cpython-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.
Diffstat (limited to 'Misc')
-rw-r--r-- | Misc/NEWS | 10 |
1 files changed, 10 insertions, 0 deletions
@@ -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 |