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-04 13:36:38 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!news.maxwell.syr.edu!news.he.net!cyclone-sf.pbi.net!151.164.30.35!cyclone.swbell.net!bos-service1.ext.raytheon.com!dfw-service2.ext.raytheon.com.POSTED!not-for-mail Message-ID: <3E403235.FC6136C8@raytheon.com> From: Mark Johnson X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: tasking programs built with GNAT insensitive to SIGTERM References: <6a6390b8.0301290704.7880bb16@posting.google.com> <3E384D9E.73123184@raytheon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 04 Feb 2003 15:35:49 -0600 NNTP-Posting-Host: 192.27.48.39 X-Complaints-To: news@ext.ray.com X-Trace: dfw-service2.ext.raytheon.com 1044394596 192.27.48.39 (Tue, 04 Feb 2003 15:36:36 CST) NNTP-Posting-Date: Tue, 04 Feb 2003 15:36:36 CST Organization: Raytheon Company Xref: archiver1.google.com comp.lang.ada:33789 Date: 2003-02-04T15:35:49-06:00 List-Id: Craig Carey wrote: > > On Wed, 29 Jan 2003 15:54:38 -0600, Mark Johnson > wrote: > > >Oliver Kellogg wrote: > ... > >> 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). > I was using the default on the machine in my office which happened to be 3.16w. This is a new version of the compiler, run time, etc. Hmm. Switching back to a 3.14 or 3.15 version calls that "unrecognized" for me as well - apparently this is something ACT just added. In looking at the run time changes in 3.16w, there are some new routines defined to "make this so", but the comments don't mention the rationale. The features file lists briefly "Better control of signal / interrupt handling" but does not go into much detail either. > >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. > I know that. I made that point when I sent this example to ACT. I am actually more concerned that SIGHUP is ignored in the same way - that can cause a remote job to stay running long after its terminal connection is lost. In the replies I have to date from Robert, he does not consider the change in behavior (from single task to multi tasking) to be a "bug". I strongly disagree. As a paying customer, I may have some leverage on this particular issue. > >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. > Delivering SIGINT (or hitting Ctrl-C) works just fine for me. From man 7 signal SIGINT 2 A Interrupt from keyboard Your sample program gets cleaned up just fine with Ctrl-C (even when built with 3.14). Are you seeing some different behavior? Note that SIGTERM and SIGHUP have different causes than SIGINT. From the same man page, all three have the same default action (terminate the process). Perhaps you have these mixed up? > > 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 ?. > Note that SIGKILL cannot be caught nor ignored. The process manager notices the killed process and takes down the whole set. The behavior you are seeing with the other signals is they can be ignored (or perhaps being caught and not acted on). I am not quite sure *why* the GNAT run time does this and I did not find the code doing that in a quick review of the source code in /usr/gnat/lib/gcc-lib/i686-pc-linux-gnu/2.8.1/adainclude. There is some rationale to what is done in the runtime in s-intman.adb (same directory) and explained more clearly in "A Detailed Description of the GNU Ada Run Time" by Javier Miranda [announced a few months ago on CLA]. But even reading through all this, I don't see the rationale for ignoring the non-reserved signals. Also - it is a "well known bug" that Linux threads do not handle signals in a Posix compliant manner. Check comp.programming.threads and see a number of discussions about that particular issue. It seems to come up as a topic about once a quarter or so. As I see it, there is both a OS and run time bug here. If you handle the signal (as in your sample code), the GNAT run time on Linux will ignore that signal on all threads EXCEPT the one handling the signal. Our particular solution for this was to "killpg" the process group so the signal gets delivered to all the threads (and ignored by all but one). --Mark