David Mason: > Fossil appears to be careful with memory allocation too, with very few > raw calls to malloc, so memory allocations can be unwound.
SQLite has the "Zero-malloc" and "Application-supplied memory allocators" options [0], which may be helpful for cases without proper db engine shutdown? On the other hand, at least the first option may not be a good choice for Fossil's heavy-lifting work? [0] https://www.sqlite.org/malloc.html Also, I've recently come across an article to solve a problem with memory fragmentation by using private heaps [1]. This way, the library could simply dispose the entire heap when done, and also "have the system do the cleanup". Or is this too heavy-weight for a library, or not supported on all systems? [1] https://blogs.msdn.microsoft.com/ricom/2006/02/02/unmanaged-memory-fragmentation-an-old-story/ --Florian _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users