On 9/17/21 5:53 PM, Dimitry Sibiryakov wrote:
Alex Peshkoff via Firebird-devel wrote 17.09.2021 16:13:
First of all dynamically loaded libraries are unloaded in reverse
order, next invoken executable dtors/atexits, and only after it -
dtors of linked libraries.
Ah, ok. But returning to the topic: which library must provide
pooled memory manager for the rest?
Currently none does - each has own memory manager. fbclient can provide
memory manager for the rest - it will be loaded first and unloaded last.
Probably the best solution would be to drop the pools completely and
get back to use system memory manager. It was significantly improved
during passed 20 years.
The only library that neeeds pooled MM from performance POV is engine. I
doubt any system MM can provide such speed of memory deallocation as
delete by pool. All the rest of modules always use single pool - but as
an additional cherry on a cake we have very fast, efficient and (last
but not least) familiar for developers support of hunting for memory leaks.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
