On Fri, 2020-05-15 at 16:38 -0400, Jeffrey Walton wrote: > On Fri, May 15, 2020 at 4:23 PM Paul Eggert <egg...@cs.ucla.edu> > wrote: > > On 5/15/20 10:52 AM, Kamil Dudka wrote: > > > I do not understand why you take it personally. > > > > I didn't take it personally. The email in question wasn't even > > directed at me. I do value civility, though. > > It was a statement of fact.
It's an opinion. You have provided examples of places where final free is important and necessary (code which is loaded as a shared library and unloaded again, while the process continues to run). I can provide examples of places where final free is clearly the wrong thing: I have worked on programs which run on large systems and can use 100G or 200G or more of RAM: going through all that memory to free it up, with associated swap reload etc., can cause process shutdown to take, literally, minutes and cause significant load on the system. Simply invoking _exit(), on the other hand, takes a fraction of that time with little extra load. In a highly-available system that difference is absolutely crucial. Final free is one legitimate way to manage memory at process exit, certainly, but _exit() (or the equivalent) is also a legitimate choice. Which one is correct depends on the judgement of the developers, based on the needs and usage of a particular project, and shouldn't be subject to dogma on either side. > To fix this problem you need to fix GNU itself. They need new blood > in leadership that understands and embraces modern engineering > processes. Whatever the intent of the previous comment, this one certainly violates the Kind Communications guidelines.
