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:
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
----------
More information about the Comp.unix.i386
mailing list