Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!pasteur!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: Summary - lost of SIGIO signal in SunOS4.1/4.0.3
Message-ID: <13904@dog.ee.lbl.gov>
Date: 4 Jun 91 17:05:32 GMT
References: <27089@adm.brl.mil> <8900@drutx.ATT.COM>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 46
X-Local-Date: Tue, 4 Jun 91 10:05:32 PDT

In article <8900@drutx.ATT.COM> connors@druco.ATT.COM (ConnorsPA) writes:
>I know nothing about the various Sun OSs. However, UNIX System V Release 4
>does provide both reliable signals *and* the capability of queueing them.

Queueing, or regenerating?  I will bet it is `regenerate':

>As an example, it can be arranged that a parent process receive an
>individual signal when *each* of its child processes exits. The
>individual signals *are* queued. SIGIO can also be queued in this way.

Queueing (or counting---the only difference between keeping a list of
pending signals and keeping a count of each of 32 pending signals is in
total signal order) SIGCLD works fine, because a SIGCLD handler is
expected to perform exactly one wait() call.  Queueing SIGIO, however,
would induce disaster:

	process p sets up SIGIO and `signal queueing'
	process p is given 1 byte; 1 SIGIO is queued
	process p is given 1 more byte; 1 more SIGIO is queued
	process p finally wakes up and takes the signal and calls
		read() and gets both bytes
	process p returns from its signal handler and gets a second
		SIGIO and calls read() again and blocks

This could be cured by using non-blocking I/O, but if you are going to
use non-blocking I/O you can simply loop in the SIGIO catcher until you
get a `would block' return, and the need for signal queueing then
vanishes.  (This is how BSD-style signals work.)

If, on the other hand, signal regeneration is used, as in traditional
System V SIGCLD, reading both bytes will mean no SIGIO will be regenerated.
Note that with regenerating SysVs, a SIGCLD catcher that is written as


	void catch() {
		(void) signal(SIGCLD, catch);
		pid = wait(&status);
	}

recurses infinitely.  The order of the wait() and signal() calls must
be reversed (so that the initial wait() consumes one child---one is
guaranteed to exist---and the signal() call will generate a new SIGCLD
if any more exited children exist at that time).
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov