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,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.107.36.79 with SMTP id k76mr749094iok.32.1511916239466;
        Tue, 28 Nov 2017 16:43:59 -0800 (PST)
X-Received: by 10.157.69.72 with SMTP id p8mr19003oti.4.1511916239385; Tue, 28
 Nov 2017 16:43:59 -0800 (PST)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.kjsl.com!usenet.stanford.edu!193no281071itr.0!news-out.google.com!193ni307iti.0!nntp.google.com!193no281066itr.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Tue, 28 Nov 2017 16:43:58 -0800 (PST)
In-Reply-To: <7c246c12-77f6-45c9-a05a-9afe934df332@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=2601:191:8303:2100:5985:2c17:9409:aa9c;
 posting-account=fdRd8woAAADTIlxCu9FgvDrUK4wPzvy3
NNTP-Posting-Host: 2601:191:8303:2100:5985:2c17:9409:aa9c
References: <7c246c12-77f6-45c9-a05a-9afe934df332@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <705c80ad-2338-4c81-b2b5-d5ea5e2b5b62@googlegroups.com>
Subject: Re: Strange warning message
From: Robert Eachus <rieachus@comcast.net>
Injection-Date: Wed, 29 Nov 2017 00:43:59 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Xref: reader02.eternal-september.org comp.lang.ada:49231
Date: 2017-11-28T16:43:58-08:00
List-Id: <comp.lang.ada>

On Monday, November 27, 2017 at 3:40:41 AM UTC-5, reinert wrote:
> Hei there,
>=20
> when I compile the enclosed program with option "-gnatwa" (i.e. "gnatmake=
 -gnatwa test1k.adb", I get the following annoying warning:=20

This is not about the warning, but overthinking the problem.  ALL tasks tha=
t declared at the library level are "fire and forget" from the point of vie=
w of the main program, and it is the only sane way to get this behavior.  1=
0.2(25) requires that all such tasks complete (or are waiting at a terminat=
e alternative) for the program (partition) as a whole to complete.

Note that it is the parent of the task that matters here, not whether or no=
t it is of a task type.  If you need to fire off tasks, but don't know the =
number of tasks needed until the main program is running, you will need a t=
ask type, and an access type both declared in a library package:

package Workers is
  task type Worker;
  type WA: access Worker;
end Workers;

You can track the existence of Worker tasks or not.  I have a number of pro=
grams where the main program figures out how many Workers are needed, spawn=
s them, and sits around waiting so it can print out a timestamp.  It is muc=
h easier to put all the Workers inside the main program to do this.  If  yo=
u need tasks whose master is the environment task and some global close beh=
avior, that can get messy.  But I've never had the problem.

Um.  I have to explain that.  If you need library level tasks, go right ahe=
ad.  Create a task with two entries, basically a counting semaphore.  All t=
he worker tasks call Add in their elaboration code, and Remove just before =
completing.  Now it the body of that task, you have a place for your last w=
ishes.  Why is this sometimes needed?  If you have a distributed program ac=
ross hundreds of nodes, you end up with a two or three level tree to create=
 all the per node worker tasks.  The main program may complete hours before=
 the worker tasks, and in fact, before all the worker tasks are created...