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.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!ucla-cs!elroy.jpl.nasa.gov!decwrl!shelby!agate!ucbvax!amstel.llnl.gov!WILSON
From: WILSON@amstel.llnl.gov (One Heppy Heppy 'Ket')
Newsgroups: comp.lang.ada
Subject: Task reuse
Message-ID: <9003010229.AA02234@ajpo.sei.cmu.edu>
Date: 1 Mar 90 01:54:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
List-Id: <comp.lang.ada>

Fred Zwarts asked about UNCHECKED_DEALLOCATION on task access types.

Mats Weber and Norman Cohen correctly responded that there is not necessarily
any effect.  Norman suggested that "good" compilers will reclaim the storage
occupied by a terminated task.  I don't know how good this really is, since I
can't rely on it from one compiler to the next, or ever from one version of a
compiler to the next!  In fact, a compiler which supports this can mask 
program bugs which might turn up at porting time.

I think that with the current Ada spec, Mats has the only right answer, which is
to maintain a task pool, and "manually" keep track of which tasks have completed
their basic function, in order to reuse them.

This seems to be a pretty general need in the Ada environment.  I am wondering
if anyone has written any generic packages which support this task pool
concept?  I've designed a few, but they've always come out too tightly coupled
to the task body's rendezvous algorithm.  Has anyone else solved this problem
in general terms, or worse, proven that it can't be solved?

			--- Rick Wilson