Hi Jan, Jan Stary wrote on Sun, May 19, 2019 at 05:46:08PM +0200: > On May 19 16:46:44, schwa...@usta.de wrote: >> Jan Stary wrote:
>>> The current "increase/decrease" wording in malloc(3) >>> can suggest it has a memory. For example, setting >>> >>> vm.malloc_conf=J >>> >>> "increases" junk level to two; >>> does setting >>> >>> vm.malloc_conf=C >>> >>> later retain a junk level of two, >>> as there is no 'j' to "decrease" it, >>> or is the junk level the defult of one now? >> Your question makes no sense whatsoever. >> First, the word "later" makes no sense. > I should have worded more clearly. I meant programs that start later, Oh. It didn't even occur to me that somebody could possibly fall prey to the misconception that anything related to a library function that is not a system call could possibly propagate from one process to another process that isn't even a child of the first one. I think the fact that we are in section 3 here and not in section 2 already makes it clear enough that whatever is described here starts from scratch for every new process and cannot depend on whatever other processes may have done before. > after vm.malloc_conf is set to something else. Well, sysctl(2) tells you that vm.malloc_conf is a *string*, so it is already clear enough that the kernel does *not* store junk levels as numbers but simply stores a string of letters. So it should be clear that first setting one string, then another one overrides the first string and can in no way be cumulative. > It makes perfect sense now, thanks. I agree nothing more seems to be missing from the documentation; at least, i don't see what might still be missing. Yours, Ingo
