Mail Archives: djgpp/1998/06/14/02:33:51
From: | George Foot <mert0407 AT sable DOT ox DOT ac DOT uk>
|
Newsgroups: | comp.os.msdos.djgpp
|
Subject: | Signal handlers -- what can they do?
|
Date: | 14 Jun 1998 06:05:04 GMT
|
Organization: | Oxford University, England
|
Lines: | 36
|
Message-ID: | <6lvp6g$onu$3@news.ox.ac.uk>
|
NNTP-Posting-Host: | sable.ox.ac.uk
|
To: | djgpp AT delorie DOT com
|
DJ-Gateway: | from newsgroup comp.os.msdos.djgpp
|
I'm not completely sure what context signal handlers are called in.
Any comments on the following questions would be appreciated.
1) Are any of the following functions remotely dangerous things to
call in a signal handler? Some are used in the default handler, so I
presume they are reasonably safe.
__dpmi_get_segment_base_address
__dpmi_get_segment_limit
__dpmi_get_memory_block_size_and_base
setjmp
exit, _exit
_creat, _write, _close
signal, raise
2) Should the memory touched be locked? I'm not sure what the
difference is between a hardware exception and a software exception.
As far as I understand it, the SIG* signals are all software
exceptions; is that right?
3) What are the consequences, within the signal handler, of
terminating the program with `_exit' rather than `exit'? The default
signal handler calls one in some circumstances, the other in other
circumstances; I'm not sure why it does this.
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.
Thanks in advance for any of this information.
--
george DOT foot AT merton DOT oxford DOT ac DOT uk
xu do tavla fo la lojban -- http://xiron.pc.helsinki.fi/lojban/lojban.html
- Raw text -