Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site sol.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!ittatc!sii!dmcnh!sol!chris
From: chris@sol.UUCP (Christopher Caldwell)
Newsgroups: net.unix-wizards
Subject: ULTRIX-11 V2.0 signal problem
Message-ID: <115@sol.UUCP>
Date: Fri, 7-Feb-86 14:55:31 EST
Article-I.D.: sol.115
Posted: Fri Feb  7 14:55:31 1986
Date-Received: Wed, 12-Feb-86 21:19:28 EST
Distribution: net
Organization: VIBRAC Corp., Amherst, NH
Lines: 127

(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