From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f94e9bacae9613b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-03 11:55:24 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-03!sn-xit-06!sn-xit-09!supernews.com!news.maxwell.syr.edu!c03.atl99!chi1.webusenet.com!news.webusenet.com!cyclone1.gnilink.net!central.cox.net!cox.net!nntp2.aus1.giganews.com!nntp.giganews.com!nntp3.aus1.giganews.com!nntp.clear.net.nz!news.clear.net.nz.POSTED!not-for-mail NNTP-Posting-Date: Mon, 03 Feb 2003 13:55:04 -0600 From: Craig Carey Newsgroups: comp.lang.ada Subject: Re: tasking programs built with GNAT insensitive to SIGTERM Date: Wed, 05 Feb 2003 08:55:18 +1300 Message-ID: References: <6a6390b8.0301290704.7880bb16@posting.google.com> <3E384D9E.73123184@raytheon.com> X-Newsreader: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Customer of Mercury Telecommunications Ltd Cache-Post-Path: drone5.qsi.net.nz!unknown@tnt1-95.quicksilver.net.nz X-Cache: nntpcache 2.4.0b5 (see http://www.nntpcache.org/) X-Original-NNTP-Posting-Host: drone5-svc-skyt.qsi.net.nz X-Original-Trace: 4 Feb 2003 08:55:01 +1300, drone5-svc-skyt.qsi.net.nz NNTP-Posting-Host: 203.97.37.6 X-Trace: sv3-Kf6bi969YOjnt3ERNuBJRaFGQ+ZfNaYPosPS9ZERssScPmousynB5HD+viKbpTMypxd/DSoF4T1wn3Z!9ILJtdiUNw0bEiE8RUagsfmlX1jGGDLL+ctKW15lZenvJcJb+l8XdLFrcmp6+PR699XFblNvM6Bj!Fok4MRg= X-Complaints-To: Complaints to abuse@clear.net.nz X-DMCA-Complaints-To: Complaints to abuse@clear.net.nz X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:33741 Date: 2003-02-05T08:55:18+13:00 List-Id: On Wed, 29 Jan 2003 15:54:38 -0600, Mark Johnson 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 ". 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