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

Reply via email to