ULTRIX-11 V2.0 signal problem
Christopher Caldwell
chris at sol.UUCP
Sat Feb 8 05:55:31 AEST 1986
(Beware: This uses the DEC system call "sigsys(2)" (embedded in the DEC
routines "sigset(3)". This mechanism is meant to correct for early
UNIX signal difficulties. I assume that persons not familiar with ULTRIX-11
and signalling mechanisms will probably not want to read any further.)
We are running ULTRIX-11, V2.0 on a PDP-11/73 system with a meg of memory.
The following C program acts as a random number generator:
=========================================================================
#include <stdio.h>
#include <signal.h>
long intcounter;
interupt() { intcounter++; }
main(argc,argv)
int argc;
char *argv[];
{
int i;
int parentpid;
int numproc, numsig;
parentpid = getpid();
if( (argc!=3) ||
(sscanf(argv[1],"%d",&numproc)!=1) ||
(numproc<1) ||
(numproc>10) ||
(sscanf(argv[2],"%d",&numsig)!=1) ||
(numsig<1) ||
(numsig>100) )
{
fprintf(stderr,"Usage: %s num_processes num_signals_perprocess\n",
argv[0]);
exit(0);
}
intcounter=0L;
sigset( SIGHUP, interupt );
for( i=0; i<numproc; i++ )
if( !fork() )
{
for( i=0; i<numsig; i++ )
if( kill( parentpid, SIGHUP ) < 0 )
{
perror("kill");
exit(1);
}
exit(0);
}
sleep( 300 );
fprintf(stderr,"Counter = %D.\n",intcounter);
exit(0);
}
=========================================================================
This program basically forks off "num_processes" processes which all turn
around and signal the parent "num_signals_per_process" times. The parent
sleeps and counts signals. For instance,
sigtest 10 10
should produce:
Counter = 100.
Example C-shell script and output:
=========================================================================
#
echo Sigtest 1 100 produces:
foreach x (1 2 3 4 5 6 7 8 9 10)
sigtest 1 100
end
echo
echo Sigtest 10 10 produces:
foreach x (1 2 3 4 5 6 7 8 9 10)
sigtest 10 10
end
Sigtest 1 100 produces:
Counter = 100.
Counter = 100.
Counter = 100.
Counter = 51.
Counter = 1.
Counter = 100.
Counter = 100.
Counter = 100.
Counter = 83.
Counter = 72.
Sigtest 10 10 produces:
Counter = 35.
Counter = 50.
Counter = 72.
Counter = 53.
Counter = 100.
Counter = 50.
Counter = 83.
Counter = 31.
Counter = 96.
Counter = 82.
=========================================================================
I figure that there is a chunk of memory associated with each process
which stores pending signals, and that if the kernel sees more pending
signals than it can store, it ignores them. I suppose signal
counters aren't used because they wouldn't preserve ordering. I think
matters are made worse in this program because there are multiple processes
signalling.
Question: Does anyone out there know how many signals can be
saved up before things get blown away?
I have no connection with either Digital Equipment Corporation or Bell Labs.
Thanks in advance.
Christopher M. Caldwell
decvax!ittatc!sii!dmcnh!sol!chris
VIBRAC Corporation, 16 Columbia Drive, Amherst, NH 03031, (603)882-6777
13B Bobby's Lane, Milford, NH 03055, (603)673-2249
More information about the Comp.unix.wizards
mailing list