[net.unix-wizards] Help with select

rick@cadtec.UUCP (Rick Auricchio) (05/15/85)

--------
[]
The requirement: to "watch" a file descriptor [technically, a socket for
pending connects] via select(2), AND to catch SIGCHLD signals;
-----------
Current thoughts:

	for (;;) {

	    oldmask = sigblock(1 << (SIGCHLD - 1));	/* block SIGCHLD */
	    ... scan tables for dead children and do whatever...

	    sigsetmask(oldmask);		/* allow SIGCHLD */
	    n = select(fd,&fdmask,0,0,0);	/* wait for activity */
	    switch (n) {

		case -1 : ...oops!...

		case  0 : break;  /* SIGCHLD occurred, recheck tables */

		case  1 : ... do socket accept etc...
	    }
	}
	
	sigchldcatcher()
	{
	    ...simply mark tables appropriately (nothing else!)...
	}

------------
The Problem: An interruptibility window exists between the sigsetmask() and
    the select(), which could cause me to miss a signal till the next time
    an event terminates/interrupts the select.

    One (ugly) solution is to have the select timeout and then re-select if
    nothing's happened. But this wastes CPU time.

    The original design didn't have to select at all, so the sigsetmask
    was actually a sigpause(oldmask) which worked fine...

    Any ideas?
==============================================================================
Opinions expressed have been generated solely by line-noise.
{cbosgd,decwrl,hplabs,ihnp4,seismo}!nsc!cadtec!rick    N1150G   (408) 942-1535
		"It only rains when you have something planned."

chris@umcp-cs.UUCP (Chris Torek) (05/24/85)

Whoaaaaaaaa!  *thud*  (sound of me falling off my chair)

I see you've run into the same problem I ran into on the Sun, doing
window select calls and catching SIGWINCH.  I didn't think anyone else
would ever notice and/or worry about this one.

As far as I can tell there is no way to avoid the race.  I hesitate to
suggest it, but it seems that select needs a sixth argument, namely a
signal mask. . . .

In my case, I ignored the race; the consequences of missing the event
were that an Emacs window might not update properly until you typed
another character (not terribly drastic), and the chances were pretty
slim.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland