chris@sol.UUCP (Christopher Caldwell) (02/07/86)
(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