A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-March/021173.html below:

[Python-Dev] Activating pymalloc

[Python-Dev] Activating pymallocJack Jansen Jack.Jansen@oratrix.com
Fri, 15 Mar 2002 10:54:44 +0100
On Friday, March 15, 2002, at 08:20 , Tim Peters wrote:

> [Andrew MacIntyre]
>> My OS/2 build definitely uses threads (don't remember what FreeBSD
>> ./configures to), and survives all the threading tests - which may not
>> highlight the problems you're referring to.
>
> Switching to pymalloc shouldn't be a correctness issue for code playing
> strictly by the rules.  The historical problem is that the Python C API
> exposes more different spellings for "get memory" and "free memory" 
> than you
> may believe possible, "the rules" for navigating this maze aren't
> documented, and so far all the spellings have reduced to plain "malloc" 
> and
> "free".

This may be overkill, but we could check correct usage of allocator/free 
pairs in a DEBUG build. At the end of pymem.h conditionally include 
pymemdebug.h which painstakingly replaces all the *alloc and *free 
defines with versions that go to a set of routines that check that 
something freed with PyFooBAR_FREE() has actually been allocated with 
PyFooBAR_ALLOC(). The accompanying pymemdebug.c would have magic to 
disable the inclusion of pymemdebug.h when it includes pymem.h, so the 
debugging routines actually get to use what was defined in pymem.h.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -




RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4