From owner-freebsd-hackers Fri Feb 23 0:16: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 1CC9337B4EC for ; Fri, 23 Feb 2001 00:16:03 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f1N8G2R12947; Fri, 23 Feb 2001 00:16:02 -0800 (PST) Date: Fri, 23 Feb 2001 00:16:02 -0800 From: Alfred Perlstein To: Farooq Mela Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. Message-ID: <20010223001602.E8663@fw.wintelcom.net> References: <200102230728.f1N7SW619041@guild.plethora.net> <3A96176A.CFE695F@sm.socccd.cc.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A96176A.CFE695F@sm.socccd.cc.ca.us>; from fmela0@sm.socccd.cc.ca.us on Thu, Feb 22, 2001 at 11:55:22PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Farooq Mela [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. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message