I don't think we need to cater anymore to careless code that mixes
system memory calls with O calls (e.g., if an extension gets memory
via `malloc()`, it's its responsibility to call `free()`), and if not
then `address_in_range()` isn't really necessary anymore either, and
then we could increase the pool size. O would, however, need a new
way to recognize when its version of malloc punted to the system
malloc.
Is this really feasible in a world where the allocators can be selected (and the default changed) at runtime? And what would be an efficient way of detecting allocations punted to malloc, if not address_in_range?
Getting rid of address_in_range sounds like a nice idea, and I would love to test how feasible it is -- I can run such a change against a wide selection of code at work, including a lot of third-party extension modules, but I don't see an easy way to do it right now.
--
Thomas Wouters <
thomas@python.org>
Hi! I'm an email virus! Think twice before sending your email to help me spread!