From owner-freebsd-hackers Fri Feb 23 0:23: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.prod.itd.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 64E8E37B491 for ; Fri, 23 Feb 2001 00:22:59 -0800 (PST) (envelope-from fmela0@sm.socccd.cc.ca.us) Received: from sm.socccd.cc.ca.us (pool0451.cvx15-bradley.dialup.earthlink.net [209.179.45.196]) by swan.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA11167; Fri, 23 Feb 2001 00:22:56 -0800 (PST) Message-ID: <3A961EA4.D8EA89B5@sm.socccd.cc.ca.us> Date: Fri, 23 Feb 2001 00:26:12 -0800 From: Farooq Mela Reply-To: fmela0@sm.socccd.cc.ca.us X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102230728.f1N7SW619041@guild.plethora.net> <3A96176A.CFE695F@sm.socccd.cc.ca.us> <20010223001602.E8663@fw.wintelcom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > > * 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. 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