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