Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!sgi!shinobu!odin!moose!jwag
From: jwag@moose.sgi.com (Chris Wagner)
Newsgroups: comp.sys.sgi
Subject: Re:  How to kill tasks after a user abort?
Message-ID: <4888@odin.SGI.COM>
Date: 5 Mar 90 21:54:55 GMT
References: <9003051013.aa18526@VMB.BRL.MIL>
Sender: news@odin.SGI.COM
Reply-To: jwag@moose.sgi.com (Chris Wagner)
Organization: Silicon Graphics, Research & Development
Lines: 57

In article <9003051013.aa18526@VMB.BRL.MIL>, moss@BRL.MIL ("Gary S.
Moss", VLD/VMB) writes:
> Rob Lansdale writes:
> <	So how do I assure that the parent process gets woken and becomes
> < the first process to enter the signal handler? I've (carefully) read
through
> < the signal man page several times and tried a number of variations of the 
> < SIGCLD signal catcher, but I still find that the parent process is getting
> < stuck occansionally in the printf() routine when it is about to print that 
> < the display code is shutdown (printf() -> Psema() -> blockproc() ...). This
> < printf() is part of the signal handling code.
> 
> Never ever call printf() or any of the <stdio.h> functions from a signal
> handler; unless perhaps that's the only usage of stdio in the program.  It
> will lead to potentially weird and fatal behavior if the signal interrupts
> a stdio function, causing the signal handler to re-enter printf() while the
> buffering mechanism is not stable.  Signal handlers should do as little as
> possible as far as calling library routines which maintain internal states
> which could be interrupted by the signal, malloc() is another good example.
> 
> If possible, set a global variable from your handler which can be detected
> and acted on from the main runstream.  This can be difficult, depending on
> the structure of your program, and therefore is best built into the design
> from the start.

This is always good advice. In addition, since printf and friends are
automatically
being protected from multiple shared processes simultaneously accessing
them, a signal
can easily interrupt a printf, while it has the lock protecting the
printf buffers.

As for the more general question, using shared processes is no different
than normal
Unix processes - only the parent will get SIGCLD if a child dies, and
the children will
not get signaled if the parent dies (unless the parent is a process
group leader).
Since most applications writers seem to prefer that if the 'master'
thread dies, that
all its children/salve threads die, in an upcoming release we are adding
a function
that more tightly binds share group members together.

As for SIGINT, which threads get the signal depends on what the disposition
of the signal was when you did the sproc - at that point each slave gets
its own
copy (just like fork()) of the signal mask and disposition.  Thus signal
handling is not currently a shared resource...

If you wish that the master/parent handle a signal differently than the
slaves, then
first set up the handler as you want the slaves to receive them, spawn
the slaves, then in the
parent change the handler to the one you want for just the parent...

Chris Wagner (jwag@sgi.com)