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!feeder.eternal-september.org!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Strange warning message Date: Sat, 2 Dec 2017 11:47:26 +0200 Organization: Tidorum Ltd Message-ID: References: <7c246c12-77f6-45c9-a05a-9afe934df332@googlegroups.com> <705c80ad-2338-4c81-b2b5-d5ea5e2b5b62@googlegroups.com> <51a6bff7-ca9f-44d8-a00b-9068727fb104@googlegroups.com> <67aa971f-9ea3-4a24-88d2-b3b4ec502451@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net v94UUQnWR40YekxTY9WIcwm++Cxuh3rvOkQyPdjK5e1mjbSomj Cancel-Lock: sha1:oRvvYM3oc8tB6UfYi2b7xu+0RdQ= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: Xref: reader02.eternal-september.org comp.lang.ada:49320 Date: 2017-12-02T11:47:26+02:00 List-Id: On 17-12-02 10:47 , Simon Wright wrote: > Robert Eachus writes: > >> For tasks, we have this additional constraint. You can't leave the >> scope in which a task is declared because the task can still access >> those objects. So functions, procedures, tasks and even packages can >> need to wait for all the tasks declared locally to be completed (or >> waiting at a terminate alternative). Again declaring library level >> tasks, if you don't need this complex behavior, eliminates run-time >> code to make it work. > > In my experience, when GNAT (with the default static elaboration) has > been unable to find a valid elaboration order, it's almost always been > because of library-level tasks; the binder can't tell whether the task > (which starts executing on completion of its package's elaboration) > actually makes any calls to with'd packages at that point, so assumes > the worst. That is also my experience, and I therefore isolate library-level tasks in their own packages which do _not_ provide any public operations. For example, if a subsystem is implemented by the data and operations in package Foo, but also needs a library-level task, I put the task in a child package, Foo.Tasks, which provides nothing else (so a pragma Elaborate_Body is usually needed in the declaration of Foo.Tasks). Only the main subprogram has context clauses "with Xxx.Tasks". No other package refers to the Xxx.Tasks packages. GNAT can then put all the Xxx.Tasks packages at the end of the elaboration order (before the main subprogram) and they cause no elaboration circularities. Another benefit of this separation is that it becomes easy to select the (sub)set of tasks that are included in the program. For example, unit testing of package Foo can be performed in a sequential way by not including Foo.Tasks in the unit-testing program. Another approach to the elaboration problem is to use pragma Partition_Elaboration_Policy (Sequential) to delay the activation of library-level tasks until the end of the library elaboration. I haven't tried that yet. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .