bmh@unc.UUCP (02/20/87)
I'm attempting to write a routine to handle exit conditions for
programs to be written for an IBM PC. The conditions I wish to
trap and handle in a robust manner include ^C and ^<break>. I
am using the Manx Aztec C compiler and was not successful in
getting the signal library function to work properly for me
when I passed my own routine as a argument rather than using
their predefined selections of ignoring or terminating on such
conditions.
I would be interested in hearing from people who have written
routines to do similar things (in Manx C or assembler), and examples
would be appreciated. If there is enough interest I will submit
a followup summary.
Additionally the Manx signal call only allows you to setup a
procedure for one time (apparently) as it resets the interrupt
to the default terminate meaning once your procedure is called.
Does anyone know whether this is because of DOS/PC considerations
or simply a limitation of Manx's code?
Thanks,
Brad Hemminger
{...!mcnc!unc!bmh}ballou@brahms.Berkeley.EDU.UUCP (02/20/87)
In article <972@unc.unc.UUCP> bmh@unc.UUCP (Brad Hemminger) writes: > > Additionally the Manx signal call only allows you to setup a >procedure for one time (apparently) as it resets the interrupt >to the default terminate meaning once your procedure is called. >Does anyone know whether this is because of DOS/PC considerations >or simply a limitation of Manx's code? Remarkably, it is neither. It is for compatibility with the UN*X signal function. UN*X signal resets the signal handler to the default when the signal is received. This leads to code sequences such as: #include <signal.h> main () { int my_signal_handler (); signal (SIGINT, my_signal_handler); /* rest of code for main () */ } int my_signal_handler (signum) int signum; { signal (signum, my_signal_handler); /* restore action for signal signum */ /* rest of code for my_signal_handler () */ } This can lead to interesting race conditions; it is possible for your process to be sent the same signal twice before it has had a chance to reset the signal handler for that particular signal. -------- Kenneth R. Ballou ARPA: ballou@brahms.berkeley.edu Department of Mathematics UUCP: ...!ucbvax!brahms!ballou University of California Berkeley, California 94720
dlnash@ut-ngp.UUCP (02/20/87)
In article <1006@cartan.Berkeley.EDU>, ballou@brahms.Berkeley.EDU (Kenneth R. Ballou) writes: > > This can lead to interesting race conditions; it is possible for > your process to be sent the same signal twice before it has had a chance > to reset the signal handler for that particular signal. > This does not happen because when a signal is delivered, it is blocked from further occurrence, much like an interrupt. This is from the 4.2 BSD man page for sigvec(2). Don Nash UUCP: ...!{ihnp4, allegra, seismo!ut-sally}!ut-ngp!dlnash ARPA: dlnash@ngp.CC.UTEXAS.EDU BITNET: CCEU001@UTADNX, DLNASH@UTADNX
ballou@brahms.Berkeley.EDU.UUCP (02/21/87)
In article <4735@ut-ngp.UUCP> dlnash@ut-ngp.UUCP (Donald L. Nash) writes: >In article <1006@cartan.Berkeley.EDU>, ballou@brahms.Berkeley.EDU (Kenneth R. Ballou) writes: >> >> This can lead to interesting race conditions; it is possible for >> your process to be sent the same signal twice before it has had a chance >> to reset the signal handler for that particular signal. >> > >This does not happen because when a signal is delivered, it is blocked from >further occurrence, much like an interrupt. This is from the 4.2 BSD man >page for sigvec(2). Careful! It is true that this is the case for BSD, but I will point out that (to the best of my knowledge) it is BSD specific behavior. I seem to recall a discussion some time back about SIGCHILD in comp.unix.questions (or comp.unix.wizards) where this was pointed out. Or maybe my mind has completely checked out ... -------- Kenneth R. Ballou ARPA: ballou@brahms.berkeley.edu Department of Mathematics UUCP: ...!ucbvax!brahms!ballou University of California Berkeley, California 94720