SCO Unix and Signals ...

Arne LUHRS arne at hpgnd.HP.COM
Wed May 2 20:08:22 AEST 1990

/ hpgnd:comp.unix.i386 / dwall at hpgnd.HP.COM (Darren WALL) /  4:03 pm  Apr 27, 1990 /
 Can someone help on UNIX signals....

I am trying to catch SIGUSR1 on a PC using UNIX from SCO (Santa Cruz 
Operation). Revision of the operarting system is 3.2.0f, revision of
development system is also 3.2.0f.

I issue a request to "sigaction" to specify the name of the routine to 
execute on occurence of the signal SIGUSR1. This work fine as far as I 
issue again the request each time I receive a signal.
I also issue requests to "sigprocmask" to block and unblock signal 
processing within some part of the code.

My code looks like:

sigaction (....)
while(1) {
   DUMMY = 0;
   sigprocmask (UNBLOCK,....)
   select (....)
   sigprocmask (BLOCK,....)
   DUMMY = 1;
   DUMMY = 0;
   sigaction (.....)
   sigprocmask (BLOCK,...)
   DUMMY = 1;
} /*end while*/

Routine to process the signal:

  write(pipe, data, one byte);
  if (DUMMY) printf (" Should not be there because of sigprocmask \n");

 With such code, my process get killed and I assumed it is killed on 
occurence of a signal on SIGUSR1. The printf message in sigusr1 as
never been printed, so sigprocmask (BLOCK...) effectively hold at least
occurence of one signal.

So I modified the code of the routine wich is used to process the
signal in the following way:

   write (pipe,...)
   if (DUMMY)...

 With this modification, my process survive for a longer period of
time but still get killed. So my understanding is that I am not
protected of multiple occurence of a signal (SIGUSR1) as long as
I have not entered the signal handling routine.
 Is this correct? Do you know any way to handle such a problem, I am
unfortunately working with an interface which generate signals but 
do not work directly with select.
 I have also been trying to use "sigset, sighold, sigrelse" even thought
they are not described in SCO UNIX manual. I get the same behaviour for
my process. I also replace the signal handling mechanism by a loop which
does polling, and there my process work fine but I am using to many CPU
cycle to get a good response time on my over-all process.

Darren WALL

More information about the Comp.unix.i386 mailing list