Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!marque!uunet!mcvax!unido!pcsbst!jh
From: jh@pcsbst.UUCP (Johannes Heuft)
Newsgroups: comp.unix.wizards
Subject: Re: Big Fun with Sys V signal handling
Summary: Golden Rules for Signal Handling
Message-ID: <307@pcsbst.UUCP>
Date: 1 Aug 88 09:57:11 GMT
References: <482@paisano.UUCP> <8264@brl-smoke.ARPA>
Reply-To: jh@pcsbst.UUCP (Johannes Heuft)
Organization: PCS GmbH, Pfaelzer-Wald-Str. 36, 8000 Muenchen; West-Germany
Lines: 44

In article <8264@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:

****************************************************************************
*                                                                          *
*       Rule #1:  In your signal handler, just set a flag and resume.      *
*              Have the main program loop test the flag at appropriate     *
*              points.  Don't try to do anything useful in the signal      *
*              handler itself.                                             *
*                                                                          *
*       Rule #2:  Follow rule #1.                                          *
*                                                                          *
****************************************************************************


Frame it and hang it over your bed and your desk and ...
I still find buggy signal handling routines in new AT&T releases which do not
adhere to these rules (cron ...).

However I think one should tell also the reason for these rules. Is there
any article one can refer to?

In general, those who know exactly what they are doing may break
the rules -- yet, who claims to know everything about signals ?? For example,
what happens if "flag" is a memory unit crossing page bounderies and
subsequently causes page faults when set or cleared. There should be a
specification that a page fault break should not cause a signal to
be sent to the program (until the instruction is resumed).

Thus, let the flag be a "char"! Remember: counting signals is not helpful.

SIGHOLD may change the quality of life (SVR3+) but certainly opens
fields for new bugs.

What about setjmp()/longjmp()? This is what the current implementation of
sleep(3) does. Be aware that longjmp may terminate also other signal
handling routines laying underneath the actual signal handler!

Never do a malloc()/free(), or buffered IO, or exit() in a signal
handling routine.

Finally, avoid Sys V signals wherever possible.

		Johannes Heuft
		unido!pcbst!jh