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!mx02.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Abortable Timed Action
Date: Sat, 09 Jan 2016 08:45:50 +0000
Organization: A noiseless patient Spider
Message-ID: <ly37u7p2dd.fsf@pushface.org>
References: <n62a4f$2fdp$1@adenine.netfront.net>
	<de0ebff1-8925-4610-b52e-23822d1a6f06@googlegroups.com>
	<n62llf$2slk$1@adenine.netfront.net>
	<446ae62f-6b95-4a4f-b253-85af071b6bf6@googlegroups.com>
	<n63r0n$12il$1@adenine.netfront.net>
	<f48a91a2-7d72-4dc4-b219-4a02b1efe237@googlegroups.com>
	<n6p5tu$9mv$1@adenine.netfront.net>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org;
 posting-host="378129f99c3c32c8ce464f7428f5f75e";
	logging-data="26442"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+IAhg/Kdi/Ek1bGZHogn6a5a8HoTvjTyg="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin)
Cancel-Lock: sha1:oAE8NIVvVzM3GqUPsrkzYSfPHHg=
	sha1:EsaNOaX7o8SPKg/mUkyMdSn5LOQ=
Xref: news.eternal-september.org comp.lang.ada:29062
Date: 2016-01-09T08:45:50+00:00
List-Id: <comp.lang.ada>

"T.G." <anon@anon.org> writes:

> The reason why I had an explicit Finish instead of using terminate was
> that I was thinking of creating the timer dynamically and then freeing
> it with Ada.Unchecked_Deallocation. So I wanted to Finish the task
> before freeing it. I'm not sure if calling Free on an access actually
> terminates the task Normally.

GNAT certainly used to have issues in this area. Indeed, you could abort
the task and then deallocate it, and end with a memory leak (the task
control block wasn't actually freed); the cure was to wait until
'Terminated.

I believe that this is no longer a problem.

> delay until is an interesting idea. I'm assuming that time drift would
> be an issue in periodic actions that repeat at a certain interval, but
> in that case delay until could also have issues if it loses some
> accuracy on each iteration.

The common solution is something like

   with Ada.Calendar;
   with Ada.Text_IO; use Ada.Text_IO;
   procedure Delay_Until is
      task T is
         entry Exec_After (T : Duration);
      end T;
      task body T is
         Start : Ada.Calendar.Time;
         Next : Ada.Calendar.Time;
         Interval : Duration;
         use type Ada.Calendar.Time;
      begin
         accept Exec_After (T : Duration) do
            Start := Ada.Calendar.Clock;
            Next := Start + T;
            Interval := T;
         end Exec_After;
         loop
            delay until Next;
            Next := Next + Interval;  -- *not* Ada.Calendar.Clock + Interval
            Put_Line (Duration'Image (Ada.Calendar.Clock - Start));
         end loop;
      end T;
   begin
      T.Exec_After (0.5);
   end Delay_Until;