Paul Taffel ([log in to unmask]) wrote:
: >>Feature?  Bug?
 
: The bottom line is that applications are expected to arm the appropriate
: Posix signal handlers for the SIGINT signal (which is what's generated
: when a Posix application sees <Control-Y>), and that there's nothing
: anyone can do (at least under MPE/iX 5.0) to prevent the SIGINT from
: propagating to all processes in the process tree.
 
: It seemed ridiculous to me that all process-handling applications should
: have to add SIGINT handlers to work-around this 'feature', but it also
: seems that there's no easy way for SIGINT to have been implemented in a
: Posix-compliant manner without having this side-effect.
 
This is very nearly the reply I would have made.  The problem here is that
the shell needs to behave like the shell on unix does - when a kill signal
comes in, processes need to die.  The shell/ix emulates this via ^y and
sends the kill signal to the process group.  Since the process group is
every process from the CI down, they all get asked to go away.
 
Although the HPSHELLINT variable in the shell can override this behavior,
it does not seem to affect the utilities.  I tried :setvar hpshellint 0
and did the above test only to find myself back at the CI.  It may be
simplest to have MKS enhance the utilities to recognize the HPSHELLINT
variable and not propogate the signal when it is not set to true.
 
: Someone from the labs would have to comment on whether future MPE/iX
: releases will allow applications to block propagation of SIGINT to
: other processes.
 
This is not planned to happen.  To get traditional applications and new
POSIX applications to interoperate better currently does require the
legacy applications to protect themselves from this behavior.
 
The request is really to have the OS differentiate on the application's
behalf, but the OS just does not have access to the information required
to even make a good guess about this.  In particular, we would have to
know in advance what the application expected because the defaults have
to be set up before the program executes its first instruction.  There
is no good apriori method of making this determination.
 
Steve