Date: Fri, 23 Feb 2001 00:26:12 -0800 From: Farooq Mela <fmela0@sm.socccd.cc.ca.us> To: Alfred Perlstein <bright@wintelcom.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. Message-ID: <3A961EA4.D8EA89B5@sm.socccd.cc.ca.us> References: <200102230728.f1N7SW619041@guild.plethora.net> <3A96176A.CFE695F@sm.socccd.cc.ca.us> <20010223001602.E8663@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > > * Farooq Mela <fmela0@sm.socccd.cc.ca.us> [010222 23:52] wrote: > > > > This is not what I am arguing. I gave a simple example of an xmalloc > > function which does just print an error and exit. However, I've written > > many large applications using this sort of scheme where when allocation > > fails, all sorts of cleanup is performed before the process exits > > (cleaning up & restoring terminal mode, gracefully closing files / > > sockets / etc, syslogging the event, etc). It is hardly ever a simple > > exit as soon as allocation fails. > > Here's exactly what's wrong with your idea: > > Some internal libc function that _can_ gracefully handle an out > of memory return will not be able to do so if your malloc wrappers > wrest control out from under them. > > Honestly, any code is somewhat flawed if it doesn't take extra care > not to have sections where an abrupt shutdown can cause a lot of > damage or inability to recover on restart. However... > > Some internal libc functions may attempt an allocation while in the > midst of doing something evil to your program such as fiddling with > signal masks or timers, if you get your "out of memory" callback > and the libc function hasn't had time to restore your normal program > context, you're going to have a world of pain to deal with. > > I can't provide any specific examples of this potentially happening, > but I can imagine it being a problem, especially deep within something > like the userland thread library or other complex library. > > If you need to deal with asprintf problems, then make an xasprinf > that does the callback in your context, not from deep within libc. I agree. Some instances of malloc failure can be / must be dealt with gracefully in libc. I am not saying that ALL usages of malloc would be replaced with calling the user-settable allocator. Only those that are not modifying, as you mentioned, the process' signal disposition and other such attributes, and *certainly* not from within the thread library. Anyway, doesnt seem like this idea is about to fly. I guess I'll shut up now. :-) -Farooq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A961EA4.D8EA89B5>