From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3e1162e60606111531g21d9acc6l9f0bf58e99cd9a08@mail.gmail.com> Date: Sun, 11 Jun 2006 15:31:15 -0700 From: "David Leimbach" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] quantity vs. quality In-Reply-To: <448B4F88.4090101@lanl.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4ef97ffa3f0bbb8004fb870726536e2c@collyer.net> <50097123-1D9F-400C-BABA-3F9A4B352733@orthanc.ca> <20060608030512.GE13116@augusta.math.psu.edu> <20060609220308.GA2291@submarine> <3e1162e60606091544p5be17e81k201735720c8c1a1@mail.gmail.com> <448A0375.5030207@lanl.gov> <3e1162e60606091638s24d2031j5e03987991206eef@mail.gmail.com> <448B4F88.4090101@lanl.gov> Topicbox-Message-UUID: 68d709aa-ead1-11e9-9d60-3106f5b1d025 On 6/10/06, Ronald G Minnich wrote: > David Leimbach wrote: > > On 6/9/06, Ronald G Minnich wrote: > > > >> Latchesar Ionkov wrote: > >> > Another example is using emalloc in libraries. I agree that it is much > >> > simpler to just give up when there is not enough memory (which is also > >> > not very likely case), but is that how the code is supposed to be > >> > written if you are not doing research? > >> > >> yes, that is a problem with a lot of code. "Just bail on first error" -- > >> we've had to stop using emalloc here because that is very unrealistic > >> for production support. > >> > >> ron > >> > > > > Well I wonder what people typically do when they can't malloc anymore > > memory but need more... A reasonable thing to do is to die I'd think. > > example. > > xcpu server is running a couple hundred processes for testing. It is > asked to do one more. It can't allocate something. > > Just dying at that point is really a bad idea, and we did find that some > of the libraries we were using would in fact do that, without coming > back to xcpu server main code with an error. That's not good behaviour > for xcpu server. It should gracefully return 'no more room' and keep > managing things; in some few cases, the library did not give us that > option. I agree with you wholeheartedly. However there are times when you *need* to malloc more memory but can't, based on how the program in question is supposed to operate. Having implemented parts of MPI's Dynamic Process Management specification before, I totally understand where you're going. I do find that, however, when I need to malloc more memory, not getting what I ask for from malloc is not an acceptable run of the program. This happens to me more often than the recoverable cases in fact, so I often call "abort" when malloc comes back NULL (in testing anyway... core dumps are handy). > > There are lots of cases like this, many of them in the kernel even; > would we want the kernel to just toss chunks at these times? Well in the kernel I agree it's a totally different ball game. There are blocking and nonblocking memory allocators (in linux anyway).