[Tim] > Long-term we should teach PyMalloc about Python's realloc() > abuses and craft a cooperative solution. [MAL] > That's what I think too. There's really not much point in trying > to work around poor malloc() implementations when we've already > got the cure built into Python... The point *here* is that a simple localized patch could kill off a Frequently Irritating Complaint without further ado: on my personal cost/benefit scale, it's all I can *afford* to do now. PyMalloc likely won't solve it as-is x-platform, without new work to accommodate extreme realloc() abuse. > I just wish Vladimir would resurface again to complete his great > work I'd like him to come back even if he doesn't <wink>. > (AFAIK, pymalloc still has problems with threads). It has lock macros that haven't been #define'd to do anything yet. But part of the potential value of the Python core using its own allocator is to exploit the global interpreter lock to *not* lock in the allocator. Messy issues. Python should grow a cheaper platform-specific flavor of internal lock too. (Jeremy pointed out some code the other day that jumps through hoops to simulate a reentrant lock on top of a Python lock; an irony is that on Windows, the native lock *is* reentrant already, and Python jumps through hoops to make it act as if it weren't <wink>)
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