demasi@paisano.UUCP (Michael C. De Masi) (07/26/88)
Hello Wizards,
This is, I guess, more of a general question than I usually
post. Can anybody out there point me towards a generalized
text on strategies to process signals in a full screen run
time unix environment? Several applications around here
are having great troubles with the concepts involved here,
and it's hard to give them hard and fast rules that have
any meaning to their plight.
We do understand the basics behind signal() and the rest
of the signal handling facilities supplied with the system,
that's not the problem. The problem is developing some
set of strategies which will allow our programmers to use
these facilites in a coherent and useful fashion.
Any suggestions would be greatly appreciated, including
those which simply represent your personal views on the
subject. Please email if possible.
Thank you,
Michael C. De Masi - AT&T Communications (For whom I work and not speak)
2340 Dulles Corner Blvd. Herndon, Virginia 22071 Phone: 703-834-8123
UUCP: decuac!grebyn!paisano!demasi
"All things considered, I'd rather be in Philadelphia" - W C Fieldsgwyn@brl-smoke.ARPA (Doug Gwyn ) (07/29/88)
In article <482@paisano.UUCP> demasi@paisano.UUCP (Michael C. De Masi) writes: >This is, I guess, more of a general question than I usually >post. Can anybody out there point me towards a generalized >text on strategies to process signals in a full screen run >time unix environment? Several applications around here >are having great troubles with the concepts involved here, >and it's hard to give them hard and fast rules that have >any meaning to their plight. 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.
jh@pcsbst.UUCP (Johannes Heuft) (08/01/88)
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!jhgwyn@smoke.ARPA (Doug Gwyn ) (08/02/88)
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.
henry@utzoo.uucp (Henry Spencer) (08/03/88)
In article <307@pcsbst.UUCP> jh@pcsbst.UUCP (Johannes Heuft) writes: >However I think one should tell also the reason for these rules. Is there >any article one can refer to? For starters, try the X3J11 draft C standard, soon to become the ANSI C standard, which explicitly says that setting a flag -- subject to some further conditions -- is the only thing a signal handler can safely do. -- MSDOS is not dead, it just | Henry Spencer at U of Toronto Zoology smells that way. | uunet!mnetor!utzoo!henry henry@zoo.toronto.edu