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-Thread: a07f3367d7,e69505d5161d7d41
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!news.albasani.net!feeder.motzarella.org!news.motzarella.org!eternal-september.org!not-for-mail
From: Reto Buerki <reet@codelabs.ch>
Newsgroups: comp.lang.ada
Subject: Re: Interrupt handler and Ada.Real_Time.Timing_Events
Date: Sat, 16 May 2009 02:20:54 +0200
Organization: A noiseless patient Spider
Message-ID: <4A0E06E6.4000209@codelabs.ch>
References: <guk532$u44$1@news.motzarella.org>
 <d963de18-83f6-4f92-a30b-39b7f9dfc4d3@r34g2000vbi.googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: news.eternal-september.org
 U2FsdGVkX19Ffbd8v+bsMTTTnmLzxNfxxTGlF60nxlC9Gd3UDv8drYZ61wVzDO2fdVblYOKVyCgh+SBHmRdj4Byn3esP66UtgJm/n3R24iWSUeIaSVHgMrl3ZbGww690vrXhPe/iReLuxVQrB4Sq6A==
X-Complaints-To: Please send complaints to abuse@motzarella.org with full
 headers
NNTP-Posting-Date: Sat, 16 May 2009 00:20:52 +0000 (UTC)
In-Reply-To: 
 <d963de18-83f6-4f92-a30b-39b7f9dfc4d3@r34g2000vbi.googlegroups.com>
X-Auth-Sender: U2FsdGVkX184kS7xV0pk5oqWp0jxTwMlDGS5HuE7zDQ=
Cancel-Lock: sha1:cYf71+vxj/yceD25lM3g+Zm72gc=
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
Xref: g2news2.google.com comp.lang.ada:5865
Date: 2009-05-16T02:20:54+02:00
List-Id: <comp.lang.ada>

Ludovic Brenta wrote:
> On May 15, 6:26 pm, Reto Buerki <r...@codelabs.ch> wrote:
>> What could be the cause for this behavior? Is there a problem with this
>> code?
> 
> Ada.Real_Time.Timing_Events's elaboration block creates a task and
> promotes it to an outer level (i.e. it is no longer dependent on a
> master).  The only way to terminate this task is by sending it
> SIGTERM, so the task attaches another signal handler to SIGTERM before
> yours.  That handler catches the signal and does not propagate it to
> any other handler.  See System.Task_Primitives.Operations.Initialize.
> 
> I'm afraid there is no way out :) maybe you can use another signal in
> your task?

I tried attaching the handler to various signals. As soon as the timer
task is started in the Ada.Real_Time.Timing_Events elaboration block, my
own handler is not triggered any more. This seems odd.

We are using Ada.Real_Time.Timing_Events to implement an event-driven
architecture in our application. The Timing_Event type seemed perfect
for this.

Nevertheless, the application should still be able to react to signals
it may receive from the operating system. Is it really Timing_Events XOR
interrupt handling?