braner@batcomputer.TN.CORNELL.EDU (braner) (09/22/86)
[] So there's one more reason NOT to use the GEMDOS Malloc() for intensive dynamic allocation. It evidently was NOT designed for that!!! (It was designed for the progressive installing of accessories & applications into memory, along with their workspaces, during a typical work session.) If your program does many malloc() calls for small pieces of RAM, and then free()s them up (e.g. microEMACS stores each line of text that way, and makes a new copy if it gets longer!), then you should use your own malloc() that gets a BIG piece of RAM from GEMDOS and then manages it itself. One such routine is part of the Megamax library. Another is shipped with Micro C-Shell. DO NOT USE Malloc()!!!!! A question: when a C program exit()s, does it clean up the malloc()ed space? This relates to the following: Challenge: can anybody devise a way to stop a running program that does not do any I/O (i.e. does not respond to ctrl-C), but WITHOUT rebooting!? (I currently embed calls to keybrk() here and there in my loops, where keybrk() is just a call to GEMDOS to see if ctrl-C was pressed, and an exit() if it was... - that works but is ugly!) - I would like some program that responds to an interrupt (say the alt-Help) and stops the currently running application, in a clean way (no crashes or reboots, ability to do it repeatedly in a session). I would like this ditty to be a separate program that you run once and then it sits resident in RAM. I have tried such a thing, with the interrupt handler doing an RTE to itself and then calling gemdos(0) - but I get mysterious crashes after a few uses! Any ideas? - Moshe Braner