Path: utzoo!mnetor!uunet!husc6!hao!ames!pasteur!ucbvax!unisoft!gethen!bdt!david From: david@bdt.UUCP (David Beckemeyer) Newsgroups: comp.sys.atari.st Subject: Re: C and autostarting GEM programs Message-ID: <176@bdt.UUCP> Date: 14 Mar 88 18:40:34 GMT References: <167@bdt.UUCP> <1008@atari.UUCP> Reply-To: david@bdt.UUCP (David Beckemeyer) Organization: Beckemeyer Development Tools, Oakland, CA Lines: 27 In article <1008@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >It *is* just a simple longjmp! (Except that it gets executed in Super >mode -- but the handler can just consist of a longjmp.) If you have a... If the Pterm handler consists of just a longjmp, doesn't that mean that the supervisor stack is permanently shrinking, and that the program thereafter runs in supervisor mode, even if it was started in user mode? Wouldn't that mean that a lot (maybe not so many) ^C's would use up all the supervisor stack? Also what about open files? SOmebody has to take care of them don't they? If the program re-opens the same files, things could get messy (one problem is the great duplicate file name thing). >Other globals have always had that problem, though: if you longjmp, >you have to be sure you reinitialize them. This statement alone (along with others in your message) suggest that the Pterm handler is more than just a longjmp. I still contend that the Pterm handler must "clean up whatever needs cleaning up, and then longjmp". The list of "whatever needs cleaning up" is where things can get complicated (potentially). -- David Beckemeyer | "To understand ranch lingo all yuh Beckemeyer Development Tools | have to do is to know in advance what 478 Santa Clara Ave, Oakland, CA 94610 | the other feller means an' then pay UUCP: ...!ihnp4!hoptoad!bdt!david | no attention to what he says"