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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Termination of periodic tasks Date: Tue, 17 Jun 2014 14:55:02 +0200 Organization: cbb software GmbH Message-ID: <1d268gqj2j3ck$.zuhlkzretdfb.dlg@40tude.net> References: Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: QTaafVZuunHujkJPndFR7g.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:20395 Date: 2014-06-17T14:55:02+02:00 List-Id: On Tue, 17 Jun 2014 09:00:47 +0000 (UTC), Natasha Kerensikova wrote: > On 2014-06-17, Dmitry A. Kazakov wrote: >> [...] >> ------------------------------------------------------- >> with Ada.Text_IO; use Ada.Text_IO; >> with Workers; use Workers; >> >> procedure Test is >> X : Manager; >> begin >> delay 5.0; >> Put_Line ("Good bye!"); >> end Test; >> ----------------------------------------------------- >> >> X is finalized before Workers (and Worker_Ptr), so it does not wait for all >> instances to terminate. > > As far as I can tell from my experimentations, this only works because > Test here is a procedure. The code I linked on github a few posts ago > also works fine that situation, since procedure-wide Cron_Entry objects > are finalized, and when the last one is finalized the tasks terminates. > > The problem I'm trying to work around is when your X here is declare in > a package rather than a procedure: > > with Workers; use Workers; > package Test_Library is > procedure Hello; > > X : Manager; > end Test_Library; OK. Moving it to the library level would make X and the task sharing the same master. In which case any Finalize to be called after completion of all dependent tasks. When X is in a procedure then its master is the procedure and things work. If you want a library level task, then the controlling object to shoot it down must be at least one level deeper. I thought about a schema when a dedicated library-level task could trigger killing other library tasks: task body Killer is X : Event; -- Want its Finialize called upon completion begin select accept Dummy; -- No matter or terminate; end select; end Killer; and then from the Event's Finalize you could kill all other tasks pending. I am not a language lawyer and cannot tell if this schema must work or not. The RM is silent about the order in which tasks are awaited. If the tasks shall be able to complete in any possible order this must be considered illegal. [Which I would say is a bit over the top a requirement.] If there shall exist at least one order in which they can complete, it could be legal. But let's ask our language lawyers... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de