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.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5dba30d6260ef552 X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: Elaboration Order Date: 1999/11/22 Message-ID: <81c1jv$b2a$1@nnrp1.deja.com>#1/1 X-Deja-AN: 551690080 References: <80pcdf$7u5$1@nnrp1.deja.com> <80s1h2$6fu$1@nnrp1.deja.com> X-Http-Proxy: 1.0 x43.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Mon Nov 22 18:21:58 1999 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-11-22T00:00:00+00:00 List-Id: In article , Simon Wright wrote: > And your compiler (well, binder) may not be able to tell > whether there is an elaboration problem or not; _you_ may know > that the task only makes a problematic call after it has been > allowed to start via some rendezvous, which won't happen until > the whole program has elaborated, but the _compiler_ may not. > > The cases where I've had this problem have both felt a bit > unsatisfactory when I reviewed the design. In GNAT, we have recently added the Restrictions pragma pragma Restrictions (No_Entry_Calls_In_Elaboration_Code); This is checked statically by the compiler. It corresponds to pretty much the normal situation in most programs. It is not uncommon to have tasks start at elaboration time which immediately hang on an accept. It is much less usual to start these tasks off for real during elaboration by making entry calls. In the presence of this restrictions pragma (which could almost be the default, we discussed making it the default in fact, but decided against it), the compiler knows that such task bodies do not get beyond the first accept, and thus we can ignore elaboration issues from calls in subsequent code. A bit kludgy, but then the whole idea of starting tasks at elaboration time, which are free to do anything before the rest of the program is fully elaborated is a nasty one, and this kind of thing is not easily consistent with static elaboration. That being said, if you follow the general design principles of: 1. Never start stand alone tasks in elaboration code 2. Always define separate task types 3. Put the instances of tasks in separate units from the task types. You can most often get a reliable static elaboration order without needing this restrictions pragma. The above principles seem good ones to me in any case, and probably relate to the "felt a bit unsatisfactory" in above above quote Sent via Deja.com http://www.deja.com/ Before you buy.