Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!hpcc01!hpbbn!hpgnd!arne
From: arne@hpgnd.HP.COM (Arne LUHRS)
Newsgroups: comp.unix.i386
Subject: Re: SCO Unix and Signals ...
Message-ID: <2640005@hpgnd.HP.COM>
Date: 2 May 90 10:08:22 GMT
References: <2640004@hpgnd.HP.COM>
Organization: Hewlett-Packard, GND
Lines: 69

/ hpgnd:comp.unix.i386 / dwall@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:

main()
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:

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


 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:

sigusr1();
  sigprocmask(SIG_IGNORE,....);
   write (pipe,...)
   if (DUMMY)...
   return;

 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
----------