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.172.71 with SMTP id v68mr1610009ioe.43.1511951977390; Wed, 29 Nov 2017 02:39:37 -0800 (PST) X-Received: by 10.157.83.199 with SMTP id i7mr53261oth.3.1511951977257; Wed, 29 Nov 2017 02:39:37 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.kjsl.com!usenet.stanford.edu!193no562385itr.0!news-out.google.com!193ni887iti.0!nntp.google.com!193no562381itr.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 29 Nov 2017 02:39:36 -0800 (PST) In-Reply-To: <705c80ad-2338-4c81-b2b5-d5ea5e2b5b62@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=85.167.214.134; posting-account=bPTmZAoAAAC_6HP9XLKB9aAAxBa6BuOR NNTP-Posting-Host: 85.167.214.134 References: <7c246c12-77f6-45c9-a05a-9afe934df332@googlegroups.com> <705c80ad-2338-4c81-b2b5-d5ea5e2b5b62@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <51a6bff7-ca9f-44d8-a00b-9068727fb104@googlegroups.com> Subject: Re: Strange warning message From: reinert Injection-Date: Wed, 29 Nov 2017 10:39:37 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:49243 Date: 2017-11-29T02:39:36-08:00 List-Id: Sorry for showing a bit confusion here, but could you indicate in few words= what is a "task declared at the library level" ? A task declared i package= "above" the main program? I refer i John Barnes: "Programming in Ada 2012" at the top of page 531 (ab= out tasks created through access types): "Furthermore, such tasks are not d= ependent upon the unit where they are created but are dependent upon the bl= ock, subprogram body or task body containing the declaration of the access = type itself".=20 Then it is "fire and forget" ?=20 I may approach better understanding now. Hopefully :-) reinert On Wednesday, November 29, 2017 at 1:44:14 AM UTC+1, Robert Eachus wrote: > 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. "gnatma= ke -gnatwa test1k.adb", I get the following annoying warning:=20 >=20 > This is not about the warning, but overthinking the problem. ALL tasks t= hat declared at the library level are "fire and forget" from the point of v= iew of the main program, and it is the only sane way to get this behavior. = 10.2(25) requires that all such tasks complete (or are waiting at a termin= ate alternative) for the program (partition) as a whole to complete. >=20 > Note that it is the parent of the task that matters here, not whether or = not it is of a task type. If you need to fire off tasks, but don't know th= e number of tasks needed until the main program is running, you will need a= task type, and an access type both declared in a library package: >=20 > package Workers is > task type Worker; > type WA: access Worker; > end Workers; >=20 > You can track the existence of Worker tasks or not. I have a number of p= rograms where the main program figures out how many Workers are needed, spa= wns them, and sits around waiting so it can print out a timestamp. It is m= uch easier to put all the Workers inside the main program to do this. If = you need tasks whose master is the environment task and some global close b= ehavior, that can get messy. But I've never had the problem. >=20 > Um. I have to explain that. If you need library level tasks, go right a= head. Create a task with two entries, basically a counting semaphore. All= the worker tasks call Add in their elaboration code, and Remove just befor= e completing. Now it the body of that task, you have a place for your last= wishes. Why is this sometimes needed? If you have a distributed program = across hundreds of nodes, you end up with a two or three level tree to crea= te all the per node worker tasks. The main program may complete hours befo= re the worker tasks, and in fact, before all the worker tasks are created..= .