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: 103376,ea9fbf0f08e5af8a
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!feeder.news-service.com!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Delayed deallocation of non-terminated task in Gnat?
Date: Wed, 31 Aug 2011 22:53:30 +0100
Organization: A noiseless patient Spider
Message-ID: <m2y5y9dz8l.fsf@pushface.org>
References: <31ba531d-fa8e-40f3-97bc-c9112b329fe2@14g2000prv.googlegroups.com>
	<1k4finucoux98.7be4jx6iy5kx$.dlg@40tude.net>
	<wccmxep30xh.fsf@shell01.TheWorld.com> <j3m5aj$pv6$1@dont-email.me>
	<wccmxepcmp0.fsf@shell01.TheWorld.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx04.eternal-september.org;
 posting-host="dFCm8HWntFqmDIilBLqEJQ";
	logging-data="30060"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19sYAr1q98irHi0esL++QOImawZ2zaTyM0="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (darwin)
Cancel-Lock: sha1:lAm3fIhu0NjnRsxVjx1LULHt8BA=
	sha1:YpmTEF2OOadHDvH7yY/KqSM2igk=
Xref: g2news2.google.com comp.lang.ada:21776
Date: 2011-08-31T22:53:30+01:00
List-Id: <comp.lang.ada>

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> You can loop, checking 'Terminated, with a delay.  But the delay is
> guaranteed to be either too long or too short -- most likely both.
> The feature we're talking about was implemented because there was such
> a loop, and it was causing an AdaCore customer's program (with
> thousands of dynamically allocated tasks) to take half an hour.  After
> implementing this feature, and removing the loop-with-delay, it took a
> few seconds.

We couldn't afford to wait, so once we discovered the leak we arranged
that all tasks to be deleted were aborted and placed on a special list;
a low-priority task did the loop-with-delay-until-terminated and then
the U_D.

   generic
      type Task_Type (<>) is limited private;
      --  The class's task type (T).
      type Task_Type_P is access Task_Type;
      --  The class's pointer-to-task (T_P).
      with function Is_Terminated (It : Task_Type_P) return Boolean;
      --  We can't say that Task_Type is actually a task, so we can't use
      --  'Identity.
   package ColdFrame.Task_Deletion_G is
      procedure Free (It : Task_Type_P);
      --  Puts It on the queue of tasks to be freed.
   private

(a) all the instantiations and calls of this code were autogenerated, so
the developer pain was minimised; 

(b) we didn't have many task deletions (mainly on network disconnects).