man@cs.brown.edu (07/05/89)
I've written a program which allocates memory using NewHandle and SetHandleSize. I have my own routines UtilNewHandle and UtilSetHandleSize which call the toolbox routines and then check MemError() to see if the call succeeded. When I detect an out-of-memory condition, I'd like to put up an alert box and then abort. I have two problems: 1) It seems that I sometimes run crash with an out of memory before I get a chance to call MemError. 2) I crash when I try to put up an alert. I have tried to fix this by calling CouldAlert to make sure the resource IDs are in memory to begin with, and allocating a static block (with NewPtr) that is the size of a WindowRecord + 512 bytes, which I free immediately before calling Alert, so that it can create the window. Still no luck. Does anybody have any suggestions on how to handle this? --Mark
earleh@eleazar.dartmouth.edu (Earle R. Horton) (07/06/89)
In article <9866@brunix.UUCP> man@cs.brown.edu () writes: >I've written a program which allocates memory using NewHandle and >SetHandleSize. I have my own routines UtilNewHandle and >UtilSetHandleSize which call the toolbox routines and then check >MemError() to see if the call succeeded. When I detect an >out-of-memory condition, I'd like to put up an alert box and then >abort. I have two problems: A problem with this approach is that the Toolbox and Operating System need to allocate space in your application's heap, in addition to what you use directly. When you only check for out-of-memory, you run the risk of not having enough of a free memory pool around for many system calls to succeed. How big your pool of free space should be is something you will probably have to determine empirically, but you will need one. One possible solution, since you process memory requests through your own filter routines, is to check the amount for free memory before calling NewHandle and SetHandleSize. If you see that memory is getting low, then you can warn the user with an alert before operation becomes unsafe. If you make sure that the free pool is always big enough, then you will not get memory-related system errors, and you will have enough memory to put up the alert box. This is more friendly to the user than waiting until memory requests fail before you take action. Another option is to reserve a largish block of memory which can be released if things get tight. You can use a GrowZone procedure to release this block, thereby making the space available to system routines. When the GrowZone procedure is called, then you release the block, assuring that the current memory request succeeds, but you also set a global variable to indicate that future requests have a chance of failure. Earle R. Horton "People forget how fast you did a job, but they remember how well you did it." Salada Tag Lines