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,2968b7d68d1e26f4 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-05 08:18:48 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!cambridge1-snf1.gtei.net!news.gtei.net!bos-service1.ext.raytheon.com!dfw-service2.ext.raytheon.com.POSTED!not-for-mail From: Mark H Johnson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: gnat/linux:setitimer References: <0e07tb.cha.ln@pa112.osielsko.sdi.tpnet.pl> In-Reply-To: <0e07tb.cha.ln@pa112.osielsko.sdi.tpnet.pl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Mon, 05 Jan 2004 10:18:45 -0600 NNTP-Posting-Host: 192.27.48.39 X-Complaints-To: news@ext.ray.com X-Trace: dfw-service2.ext.raytheon.com 1073319526 192.27.48.39 (Mon, 05 Jan 2004 10:18:46 CST) NNTP-Posting-Date: Mon, 05 Jan 2004 10:18:46 CST Organization: Raytheon Company Xref: archiver1.google.com comp.lang.ada:4121 Date: 2004-01-05T10:18:45-06:00 List-Id: TIlman Glotzner wrote: > Hello, > > below my attempt to connect the linux system timer to an ada program. > 1) In the process list, I see the program distributed over 5 > processes. Each signal handler is mapped onto one process. One > process is probably needed for the main program. On which part > of the program are the other 2 processes mapped to ? > The GNAT implementation of tasks on Linux (up until *very* recently) has processes for - the main program - a thread manager - a thread per signal being managed - a thread per task and they show up as individual processes in ps, top, etc. We ended up writing a small library package that would write a file in /tmp/ that had our "task name" so we could correlate between PID's and tasks. When I mean "very recently", if you are using the new pthread library (e.g., Red Hat 9 or later), the rules have changed somewhat and I haven't used it enough to comment on it. > 2) When the timer expires, the timer signal (SIGALRM) is not catched > by the signal handler. The signal handlers itselves apparrently work as > the handlers react to signals sent by a unix kill command. As > process number I need to give the PID of the appropriate signal > handler. I suspect that the signal is sent to the process that > started the itimer. As the signal signal handlers run as > separated processes, the SIGALRM signal issued from the itimer does not > reach the signal handlers. What do I need to do to make it work ? > What we do instead is to: - determine the process group - use killpg instead of kill to send the signal to the process group In this case, the signal is delivered to all the threads and all but one thread will ignore it. Only the signal handler will catch it and process it. > 3) Is there a unix utility that allows me to monitor signals, > i.e. which program issues which signal, and which program catches it ? > The latter part can be done with the debugger (gdb). I am not aware of any utility to tell you who sent the signal. > 4) I first tried to import the system call "setitimer", and hand over > setitimer's parameters by access types(ITimervalPtrs'address). The > program also compiles if handing over the variables directly (not > references to the variables). Is gnat/ada doing a parameter conversion to > a reference implicitly for me ? > Not sure, we have C code that actually calls setitimer in our system :-). You should be able to do something like... pragma Interface(C, Setitimer); and use declarations that are compatible with C to call setitimer directly from Ada. We do that for a lot of other functions but just not that one. You may also need pragma Unreserve_All_Interrupts; since the run time may also be trapping the specific signals you are trying to use. --Mark