[comp.unix.questions] problems with SIGALRM.....

arup@grad1.cis.upenn.edu (Arup Mukherjee) (04/09/89)

Dear netlanders,
        Can anyone tell me what is wrong with the following program?
It works fine under Ultrix 3.0 but not under earlier versions of
Ultrix. It also does not work under SunOS 4.0. Am I making some kind
of mistake, or is this a known bug? If so, are there any workarounds
that will allow SIGALRM to work properly. (Note that if I try to trap,
for example, SIGSEGV instead, and then generate a segmentation violation on 
purpose, it works on any machine).


				Thanks very much....
						
						Arup Mukherjee
					[arup@grasp.cis.upenn.edu]
---cut here---

# include <stdio.h>
# include <signal.h>

struct sigvec f;

int handler()
{
	fprintf (stderr, "I got a signal!\n");
	fflush(stderr);
}

main()
{

# ifdef TRY2                             /* neither of these two work on */
	f.sv_handler = handler;          /* most machines I tried        */
	f.sv_mask = 0;
	f.sv_onstack = 0;                /* Under Ultrix 3.0 on a        */
                                         /* uVax 3500, both work ok      */
        sigvec (SIGALRM, &f, NULL);
# else 
	signal (SIGALRM, handler);
# endif  
	

	alarm(1);
	sleep(10);


}

arup@grad1.cis.upenn.edu (Arup Mukherjee) (04/09/89)

>        Can anyone tell me what is wrong with the following program?
[stuff deleted]

The explanation of my earlier problem with SIGALRM was that sleep(3) 
also happens to use SIGALRM to time the interval it sleeps for. Now, 
I'm not sure why it works under Ultrix 3.0 ......

					Arup Mukherjee
				[arup@grasp.cis.upenn.edu]

rml@hpfcdc.HP.COM (Bob Lenk) (04/12/89)

> The explanation of my earlier problem with SIGALRM was that sleep(3) 
> also happens to use SIGALRM to time the interval it sleeps for. Now, 
> I'm not sure why it works under Ultrix 3.0 ......

The Ultrix sleep() is apparently based on or compatible with System V or
POSIX, while the SunOS sleep() is apparently based on BSD.  Both use
SIGALRM.  System V's does various pushups related to a previously
requested SIGALRM to behave essentially as if it did not use the signal.
This should be described in the sleep(3) manual entries.

		Bob Lenk
		hplabs!hpfcla!rml
		rml%hpfcla@hplabs.hp.com