[comp.unix.wizards] Summary - lost of SIGIO signal in SunOS4.1/4.0.3

TAYBENGH%NUSDISCS.BITNET@cunyvm.cuny.edu (THE AGEIS) (06/03/91)

        The answer of my question is:
        Although the Sun DOES provide reliable signal, it does NOT mean
a signal counter is kept. If there are 2 instances of a same signal say SIGIO
are asserted before the first one can be serviced, only one of them will be
delivered. As a result, to handle signal properly, one must write code in such
a way that when a signal is received, it checks for all the work that may be
available from any number of a particular signal and does it all. In my case,
I use the value of the semaphore sets to check.
        Thanks for the people who helps, and sorry abt my ignorance of the true
meaning abt the reliable signal.

- Beng-Hang Tay (email: taybengh@nusdiscs.bitnet)
  Dept of Info Syst. and Comp. Sc.
  National University of Singapore

connors@druco.ATT.COM (ConnorsPA) (06/04/91)

In article <27089@adm.brl.mil>, TAYBENGH%NUSDISCS.BITNET@cunyvm.cuny.edu (THE AGEIS) writes:
> 
>         The answer of my question is:
>         Although the Sun DOES provide reliable signal, it does NOT mean
> a signal counter is kept. If there are 2 instances of a same signal say SIGIO
> are asserted before the first one can be serviced, only one of them will be
> delivered.

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.
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.

For those with manuals, check out the SA_SIGINFO parameter
to sigaction(2); and siginfo(5).

-----------------------------
 Paul Connors
 Email:	att!druco!connors
-----------------------------

torek@elf.ee.lbl.gov (Chris Torek) (06/05/91)

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

guy@auspex.auspex.com (Guy Harris) (06/06/91)

>>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':

And I will bet it's "queue"; S5R4 will, if SA_SIGINFO is specified when
the signal is caught with "sigaction()", pass, as two additional
arguments to the signal handler, a pointer to a "siginfo_t" structure
containing various information (a generalization of the BSD "code"
argument, plus the SunOS 4.x "addr" argument, containing other stuff -
e.g.  the child process ID and exit status for SIGCHLD) and a pointer to
a "ucontext_t" structure (similar to the BSD "context" argument).