On Mon, May 27, 2002 at 08:41:59AM -0700, Sean O'Rourke wrote: > Since our memory-allocating routines return NULL quite a ways back up the > call chain (all the way through e.g. string_grow()), here's another way to > do this -- if allocation returns NULL all the way to an op function, it > can make the things it wants to keep reachable from somewhere, do a > collection, and retry. By the way, neither of string_grow()'s callers > checks its return value now, which indicates to me that this may be > error-prone.
That's an interesting point, actually. What is the right thing to do when we run out of memory? - Abort immediately. This is not very user-friendly. - Return a special value. But then we need to check the return value of almost all functions (including string_compare, for instance). - Instead of returning a special value, we can set a global variable to signal the error. Again, we need to check this variable everywhere. Note that this is the solution adopted by Java. - Raise an exception using longjmp. But then, if we start using locks all over the place like in Java, we are pretty sure to leave the program in an inconsistent state. (It is neither safe to release the locks nor to keep them.) - Use a small amount of emergency memory to invoke a user-defined handler which can either release some memory or signal the problem to the user. (If the handler returns, we do another collection and we try to reserve some emergency memory again. If this succeeds, then we resume the program. Otherwise, we abort.) But how much emergency memory is enough? -- Jerome
