Date: Sun, 14 Jun 1998 14:45:10 +0300 (IDT) From: Eli Zaretskii To: George Foot 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.