>>> Reindl Harald <h.rei...@thelounge.net> schrieb am 19.02.2021 um 09:13 in Nachricht <068b561d-677f-1abf-ef9f-0f43571e1...@thelounge.net>:
> > Am 19.02.21 um 08:44 schrieb Ulrich Windl: >>>>> Lennart Poettering <lenn...@poettering.net> schrieb am 18.02.2021 um 19:30 >> in >> Nachricht <YC6yQIX+7MFLvhmc@gardel-login>: >> ... >>> entry instead of asking for new memory again. This allocation cache is >>> a bit quicker then going to malloc() all the time, but means if you >>> just watch the heap you'll assume there's a leak even though there >>> isn't really, the memory is not lost after all, and will be reused >>> eventually if we need it. >> >> That's an interesting point of view: If you save memory in case you might > need >> it at some unspecified later time (which includes "never") it's > "practically" >> (while not theoretically) a memory leak > > following that logic every memory pool and mysql buffer would be a memleak Database memory pools typically have a settable upper-bound. > > a memleak is *unintended* and never freed memory allocation, practically > as well as theoretically So for every memory leak the programmer just has to say "that's intentional" and it's no longer a memory leak ;-) > > you can argue about the size of such cases but it don't make them a > memleak to begin with With Lennart's explanation there are two unbounded dimensions: 1) the amount of "cache" 2) the time until actual re-use (With 2) leading to 1) it seems) Regards, Ulrich _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
