Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!ucsd!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: Big Fun with Sys V signal handling
Message-ID: <8295@smoke.ARPA>
Date: 2 Aug 88 06:20:21 GMT
References: <482@paisano.UUCP> <8264@brl-smoke.ARPA> <307@pcsbst.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 26

In article <307@pcsbst.UUCP> jh@pcsbst.UUCP (Johannes Heuft) writes:
>Thus, let the flag be a "char"!

The proper data type depends on the system.  In ANSI C it is denoted
sig_atomic_t.  ANSI C also specifies what can be relied on in a
signal handler.  (Basically, not much.)  There was quite a bit of
sentiment for not promising ANYthing; for example, on many systems
you cannot be sure that ANY of the code in your signal handler will
actually get executed when the signal occurs.

>Finally, avoid Sys V signals wherever possible.

Avoid all UNIXy flavors of signals whenever possible.

A truly usable scheme would require something like VMS exception
handlers, exception stack unwinding, and so on.  Even so, you'd
still need to set up guards around "conditional critical regions",
i.e. shared data structures, and for that to work right you need
a full scheme of monitors a la Brinch-Hansen.  If your system has
so-called "reliable signals", you can use the hold/block/mask
feature to prevent collision for one level, but if you need for
more than one signal handler to access the same data it gets
too messy for my taste.

What is amazing is how well old, seriously broken code has
managed to work so far.  Windows of inconsistency must not make
up a very large percent of typical applications.