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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Natasha Kerensikova Newsgroups: comp.lang.ada Subject: Re: Termination of periodic tasks Date: Tue, 17 Jun 2014 06:57:38 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: Injection-Date: Tue, 17 Jun 2014 06:57:38 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="76a49b86bc3e16725b7cfca3d85cb4c8"; logging-data="8251"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18g5h7EdfjFfHSg5cmDZbyU" User-Agent: slrn/1.0.1 (FreeBSD) Cancel-Lock: sha1:cJUQ9VnAmAJqoY39bLIVVmqVXzE= Xref: news.eternal-september.org comp.lang.ada:20385 Date: 2014-06-17T06:57:38+00:00 List-Id: Hello, On 2014-06-16, Jeffrey Carter wrote: > ARM 9.3 says, "If the task is created by the evaluation of an allocator for a > given access type, it depends on each master that includes the elaboration of > the declaration of the ultimate ancestor of the given access type." > > The master of a task designated by a Task_Access is the environment task, > assuming To_Be_Discussed to be a library unit. Meanwhile, finalization of an > object of type Watcher will happen when you exit the scope of whatever unit > declares the object. Those will usually be different if the object is declared > outside of To_Be_Discussed. I'm not clear about the case where the object is > declared inside To_Be_Discussed. So let's consider instead real code that actually (more or less) works: https://github.com/faelys/natools/blob/trunk/src/natools-cron.ads https://github.com/faelys/natools/blob/trunk/src/natools-cron.adb (I whipped it together yesterday after thinking about Dmitry's suggestion, but it's still only a rough draft, there are issues to iron out before using it for real, like handling map key collisions. However all comments are still welcome.) Global_Worker here is either null or an access to a Worker created by an allocator. Since as far as I can tell Natools.Cron is library-level, the master of the worker task is the environment task. In this implementation, the task terminates by reaching the end of its body whenever the protected map becomes empty. Storage is released only right before requested again when the protected become non-empty again, so at program termination the task memory is "leaked", but program termination is supposed to reclaim everything anyway. The finalization of a Cron_Entry removes the corresponding element from the protected map, so the worker task terminates after all Cron_Entry are finalized (or Reset to an empty state). This leaves the problem of Cron_Entry objects declared in library level packages: with Natools.Cron; package Test_Periodic is type Periodic_Action is new Natools.Cron.Callback with null record; overriding procedure Run (Self : in out Periodic_Action); Global_Entry : Natools.Cron.Cron_Entry; end Test_Periodic; with Ada.Text_IO; package body Test_Periodic is overriding procedure Run (Self : in out Periodic_Action) is begin Ada.Text_IO.Put_Line ("Hello"); end Run; begin Global_Entry.Set (1.0, Periodic_Actoin'(null record)); end Test_Periodic; Now the master of Global_Entry is also the environment task. So Global_Entry will not be finalized before the worker task terminates, but by design the worker task will not terminate before Global_Entry is finalized or Reset. So unless at some point Global_Entry.Reset is called, this package will cause the program to never terminate. Is there a way to work around such a situation? Or should I just document this as a caveat (among many others, as you can see at the beginning of the spec)? Thanks for your help, Natasha