On 9/3/07, erik quanstrom <[EMAIL PROTECTED]> wrote: > if((p = malloc(Size)) == 0) > /* malloc recovery code */ > /* why bother? the kernel could be lying to us anyway. */
Having run into issues writing codes with large memory footprints on linux (which also overcommits [by default]), erik's comment here is close to my heart. Indeed, what's the point of a malloc interface that returns 0 when in practice the kernel kills your process before that happens? It strikes me as irresponsible to advertise an interface you won't/can't honour. This is certainly my biggest problem with overcommitting. Well, that and the non determinism, but it's not clear to me that's avoidable when memory is exhausted. [EMAIL PROTECTED] wrote: > The big exception is stack growth. The > kernel automatically extends a process's stack segment as needed. OK, so the stack takes precedence over heap allocations. What if it was the other way around? Instead of stealing pages that process Y has malloc'd but not yet touched to grow the stack of process X, kill process X because there's not enough memory left to grow the stack... Mmmm. I don't think I helped anything. On the surface it looks like I'm honouring the malloc request, but there's probably a fair chance X == Y and the non-determinism really is the problem. Well, I guess the next question is: Is malloc's interface sufficient/practical? -sqweek
