Re: tasking programs built with GNAT insensitive to SIGTERM

[Craig Carey <research@ijs.co.nz>]

On Wed, 29 Jan 2003 15:54:38 -0600, Mark Johnson
<mark_h_johnson@raytheon.com> wrote:

>Oliver Kellogg wrote:
...
>> Under Linux, how come tasking programs built with GNAT
>> (3.2, but other versions as well) don't react to
>> "kill -TERM" ?
>> 
>> Is there a trick to make them killable?
>> 

For GNAT 3.15p in Linux with native threads, attaching a signal handler
for SIGTERM (see below) fixes the problem so that the thread can be
terminated with "kill -s TERM <pid>".

Unfortunately 3 new threads that ignored SIGTERM are added if the
method is used (but it is better, since all 4 die if the right thread
is TERM-ed). I sent in a bug report saying that 4 is too many.



>> See also http://gcc.gnu.org/cgi-bin/gnatsweb.pl
>> bug number 9480.
>> 
>Hmm. Very odd behavior. You can probably get what you want by using
>  pragma Interrupt_State (SIGTERM, System);
>

What is the compiler that implements a pragma 'Interrupt_State' ?.
(The GNAT compiler I tried didn't understand that pragma).

>Which forces SIGTERM to be handled as a "system" interrupt. See the GNAT

The simple example of problem 9480 did not try to handle SIGTERM signals.


>Reference Manual for more details. I ran a test program and it appears
>to do what you want it to.
>
>It is odd enough - I may forward it to ACT to see what they say about
>it.

Any information on when GNAT will run as well in Linux as it does in
Windows 200 ?: one Ctrl-C (a plain Windows signal) and the program is
100% removed from memory.

> Also note - you DO have to hit one of the threads that has that
>signal enabled to make it terminate the program. The main program is OK

Isn't that a compiler vendor or OS bug?. SIGKILL terminates all of the
4 threads no matter which of that signal is sent to, so why have only
one of the four take all four down when SIGTERM is the signal ?.


>(usually the process with the lowest PID), but the thread manager
>(usually main PID +1) has the signal masked.


Here is solution but it is not as good as would be hoped for.

(1) The 1.3 second delay statement can be replaced with a 'Timed Entry
 Call':

    AARM 9.7.2 Timed Entry Calls:
    http://www.adaic.org/standards/95aarm/html/AA-9-7-2.html

      --  A protected object stops blocking when SIGTERM was receieved
   select
      Signals.Shutdown;
      goto ... --  exit program
   or
      delay 1.3;
   end select;
   ...
  
   protected Signals is
      procedure SIGTERM_Handler;   --  unblocks the Shutdown barrier
      pragma Interrupt_Handler (SIGTERM_Handler);
      pragma Attach_Handler (SIGTERM_Handler,
                  Ada.Interrupts.Names.SIGTERM);


If the delay was much bigger than 1.3 secs, and also C's exit() was used
to close the program, then the program would readily be stuck in memory
as a zombie, at least in Linux and Linux emulators.
If exit() is not used then the Timed Entry Call is more likely to be
used.




G. A. Craig Carey
http://www.ijs.co.nz/ada_95.htm