🚀 go-pugleaf

In article <1992Dec22.163159.22768@ann-arbor.applicon.slb.com>,\
 chamber@mailhost.aa.cad.slb.com (Craig Chamberlain) writes...
> Here's another signal handling problem I've discovered.
> SIGINT, which is for CTRL-C, seems to want to be handled
> only once, even though it is reset with a new call to signal()
> each occurrence.  On the VAX my test program runs fine.
> CTRL-C must be hit on the main console three times.  On the
> Alpha, the first CTRL-C is handled, the second one isn't,
> and the third one quietly terminates the program.

     You call printf() and then longjmp() out of a signal handler and end
up surprised that there are problems?  The surprise I have is that it
seemed to work reliably on the VAX to begin with.  You can't portably call
any C library function from a signal handler except signal() itself with
the same signal number, _unless_ the handler was triggered by a call to
raise() (or abort(), but there doesn't seem any way to control it).

     I don't know whether or not DEC expects your code to continue
to work as it did on the VAX, because I haven't seen any documentation
describing what sort of portability they've tried to deliver.  I'd
rather see portable code handled efficiently than have crippled run-time
behavior in order to accomodate non-portable code such as your example.

     Try something like the following for your handler.  If it also fails
to reset itself properly, then you've got a legitimate complaint.

#include <signal.h>
volatile sig_atomic_t ctrl_c_count;

void ctrl_c_handler(int sig)
{
    ctrl_c_count++;
    signal(sig, ctrl_c_handler);
}

		Pat Rankin, rankin@eql.caltech.edu