Evan Jones wrote: >> Another is that the platform OS+libc may not shrink VM at >> times even when memory is returned to the system free(). > > > There is absolutely nothing I can do about that, however. You could if you wanted. Don't use malloc/free, but use mmap/munmap, VirtualAlloc/VirtualFree, etc. > Anyone care > to enlighten me? Microsoft ships the source of its malloc(3) implementation together with VC; you need to install the CRT source to see it. > Let me just make sure I am clear on this: Some extensions use native > threads, is that why this is a problem? Because as far as I am aware, > the Python interpreter itself is not threaded. So how does the cyclical > garbage collector work? Doesn't it require that there is no execution > going on? The garbage collector holds the GIL. So while there could be other threads running, they must not manipulate any PyObject*. If they try to, they need to obtain the GIL first, which will make them block until the garbage collector is complete. > It is also a waste if the core Python developers decide it is a bad > idea, and don't want to accept patches! :) That will ultimately depend on the patches. The feature itself would be fine, as Tim explains. However, patches might be rejected because: - they are incorrect, - their correctness cannot easily be established, - they change unrelated aspects of the interpreter, - they have undesirable performance properties, or - they have other problems I can't think of right now :-) Regards, Martin
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