From: "Charles Sandmann" Newsgroups: comp.os.msdos.djgpp Subject: Re: Signal handlers -- what can they do? Date: Sun, 14 Jun 1998 10: 5:41 Organization: Aspen Technology, Inc. Lines: 28 Message-ID: <3583a075.sandmann@clio.rice.edu> References: <6lvp6g$onu$3 AT news DOT ox DOT ac DOT uk> Reply-To: sandmann AT clio DOT rice DOT edu NNTP-Posting-Host: dmcap2.aco.aspentech.com To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk > 1) Are any of the following functions remotely dangerous things to > call in a signal handler? You can theoretically call about anything - but if some bad argument was passed to a C library routine, and it's not reentrant (I/O stuff) you might not get what you want. There is also a limited stack of 4K for hardware exceptions so avoid calling any C RTL routine which does much of anything on the stack. > 2) Should the memory touched be locked? It only must be locked if you expect an exception in a hardware interrupt. Since these always kill the machine anyway, don't bother. > 3) What are the consequences, within the signal handler, of > terminating the program with `_exit' rather than `exit'? Exit handlers don't get called. This is needed since the stack may be scrogged, or you may have corrupted structures in the exit handlers which would cause an infinite loop. > 4) As far as I can tell, my SS:ESP in a signal handler is the same as > the main application's SS:ESP when the signal occured. What happens > if the signal occured because of a stack problem? Surely under these > circumstances we can't continue to use the same stack. There is an internal 4K exception/locked stack in the image which is switched to in certain circumstances (hardware exceptions).