www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/06/14/11:45:45

From: "Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
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

> 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).  

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019