Date:	Sun, 14 Jun 1998 14:45:10 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	George Foot <mert0407 AT sable DOT ox DOT ac DOT uk>
cc:	djgpp AT delorie DOT com
Subject:	Re: Signal handlers -- what can they do?
In-Reply-To:	<6lvp6g$onu$3@news.ox.ac.uk>
Message-ID:	<Pine.SUN.3.91.980614143435.6294f-100000@is>
MIME-Version:	1.0

On 14 Jun 1998, George Foot wrote:

> I'm not completely sure what context signal handlers are called in.

They are called in the usual context of your application code.

> 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

All of these are safe, AFAIK.

> 2) Should the memory touched be locked?

Usually, no.

> 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?

In general, there is a difference, and not all signals are software
exceptions.  But please give examples to what you call ``hardware
exception'', as I'm not sure we are talking about the same things. 

> 3) What are the consequences, within the signal handler, of
> terminating the program with `_exit' rather than `exit'?

The same as when `exit' and `_exit' are called from any other function.

> The default
> signal handler calls one in some circumstances, the other in other
> circumstances; I'm not sure why it does this.

In general, `_exit' should be called in all cases, since some signals, 
like SIGSEGV, might mean a scrogged stack and other atrocities, so the 
default handler should do as little as possible before exiting.

However, since `_exit' leaves files unflushed and unclosed, SIGINT 
invoked with Ctrl-C calls `exit' instead, so that at least in the most 
popular case, when we know nothing bad can happen by exiting normally, we 
take the usual orderly path to exit.

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

That is why it's best to use as few automatic variables in the signal 
handler as possible.

- Raw text -