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: a07f3367d7,4d062d5c58234698
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
X-Received: by 10.180.74.74 with SMTP id r10mr4911668wiv.3.1356187740184;
        Sat, 22 Dec 2012 06:49:00 -0800 (PST)
Path: 
 i11ni256662wiw.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!194.109.133.87.MISMATCH!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!feeder.erje.net!us.feeder.erje.net!gandalf.srv.welterde.de!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: right compilation unit for C as main?
Date: Wed, 19 Dec 2012 10:00:33 +0200
Organization: Tidorum Ltd
Message-ID: <ajdah2FgiuvU1@mid.individual.net>
References: <b1d1bbac-0b53-4848-ae3c-92d85dc73df6@googlegroups.com>
 <kaq22c$goh$1@dont-email.me> <wcc4njjtha3.fsf@shell01.TheWorld.com>
 <lypq26yc7s.fsf@pushface.org>
Mime-Version: 1.0
X-Trace: individual.net
 ByIDV5g31mBCwTtgpV8kGAzhRjugKyafkW0z7taq6O93XJ9toYALYrMYh2njBxLV2G
Cancel-Lock: sha1:AXxB0qPA8EyGBobxw4sbdRt6fZ8=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:17.0) Gecko/17.0 Thunderbird/17.0
In-Reply-To: <lypq26yc7s.fsf@pushface.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Date: 2012-12-19T10:00:33+02:00
List-Id: <comp.lang.ada>

On 12-12-19 05:04 , Simon Wright wrote:
> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> 
>> Tasks can also be created during library-package elaboration,
>> which is called from adainit.
> 
> This is one of the few ways I've managed to cause elaboration-order
> problems with GNAT's default elaboration order algorithm.

That happened to me, too. I got around the problems by putting all
library-level tasks in packages that have no public (provided)
interface, so that these packages can be elaborated last. I usually
"with" these "task packages" only from the main subprogram.

Separating the tasks in this way also helps unit and integration
testing, because one can then build the program with any desired subset
of the tasks just by changing the "with" clauses in the main subprogram.

The converse drawback is that the absence or presence of tasks in some
subsystem is revealed at the highest design levels, instead of being
nicely hidden and encapsulated in the subsystem. Another result of this
design style is that it becomes difficult to use task entries and
rendez-vous, because of the rule that allows accept statements only in
the body of a task and not in subprograms called from the task. So I
tend to use only protected object entries.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .