On Sat, 7 Jul 2001 [EMAIL PROTECTED] wrote: > On Sat, 7 Jul 2001, Justin Erenkrantz wrote: > > > On Sat, Jul 07, 2001 at 12:26:32PM -0000, [EMAIL PROTECTED] wrote: > > > dreid 01/07/07 05:26:32 > > > > > > Modified: include apr_sms.h > > > memory/unix apr_sms.c apr_sms_trivial.c sms_private.h > > > Log: > > > Add the abort function into sms. This is largely to keep compatability > > > with pools and at present we don't do anything more than get/set, but > > > that's easily fixed. > > > > > > Question is, do we still want this capability? > > > > I don't think there is any benefit to this. But, someone else might > > be able to chime in and say why we need this functionality. -- justin > > This MUST stay. The reason is simple. A well behaved library will not > exit, or print a message to stderr. However, because APR needs to > maintain backwards compat with Apache 1.3, when we can't allocate memory, > we print to stderr, and abort. > > Unless there is another way to use APR and provide both options, the abort > function must remain.
what's it really matter? trying to clean up from OOM is near impossible. the task will be shot on linux or anywhere else with optimistic memory allocation in many situations. linux 2.4 changes the OOM situation slightly, but only in the details as to which task gets shot. (not necessarily the one which tried to access the last available free page.) and like i said in my other message, you have no idea from NULL vs. non-NULL as to whether you're out of memory yet. in fact, malloc may brk() to get more memory, then segfault while trying to lay down its structure into that memory. (linux malloc of >=128kb blocks use mmap directly and they're page aligned with no malloc structures, so the segfault doesn't happen until the application touches it... for the "why" of this study the mremap() syscall and try remallocing big regions on linux :) oh also, you might fault trying to grow the stack and that could take the task out. also, a box which is OOM desperately needs memory in order to function. either your task is going to die, or something else is. the box is probably so deep into swap that it's unuseable, and the faster you die the better for everyone. one might ask "but what about all those resources i need to unwind and release" ... and to that i'll just say: power failure. if resource mgmt is so important then you've already considered power failures and you've concluded that you need to use transaction logging techniques. (this is also why i really like things which are freed up and released properly on their own when a process exits... like kernel-based locks, and not like pthread mutexes :) i kind of gave up on memory allocation checking. i'd consider it if i was coding in ada or some language with appropriate exception mechanisms. but not in C. but i could just be jaded :) -dean
