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=-0.3 required=5.0 tests=BAYES_00,FORGED_YAHOO_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,23ffa52608fbb144 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.205.134.138 with SMTP id ic10mr2056697bkc.8.1337532501449; Sun, 20 May 2012 09:48:21 -0700 (PDT) Path: e27ni26360bkw.0!nntp.google.com!news2.google.com!news1.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!KNOLOGY.NET-a2kHrUvQQWlmc!not-for-mail From: Tim McGuire Newsgroups: comp.lang.ada Subject: Re: Problem with Delay Alternative in Finalization Date: Sun, 20 May 2012 11:46:55 -0500 Message-ID: References: <6v0er7d545kvs3pr7aqe1dnrlq4mg5ldhg@4ax.com> X-Newsreader: Forte Agent 6.00/32.1186 trialware MIME-Version: 1.0 X-Complaints-To: abuse@usenetserver.com Organization: UseNetServer.com X-Trace: 7494c4fb92181bd8f493d01794 X-Received-Bytes: 2335 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 2012-05-20T11:46:55-05:00 List-Id: On Sat, 19 May 2012 20:46:25 +0100, Robert Matthews wrote: >Dmitry A. Kazakov wrote: > >> On Fri, 18 May 2012 21:30:31 -0500, Tim McGuire wrote: >> >>> I am running in to a problem where a delay alternive used when in >>> finalization doesn't seem to be working properly. >>> The delay part never seems to happen. >> >> It is Program_Error to propagate an exception from Initialize, which is >> what I think happens when you raise Lock_Timeout_Exception. >> >> BTW, you can use task identification in order to allow reentrant locks. >> > >In the 2005 standard at 7.6.1 para 14.a: "It is not a bounded error for >Initialize to propagate an exception. If Initialize propagates an exception, >then no further calls on Initialize are performed, and those components that >have already been initialized (either explicitly or by default) are >finalized in the usual way." > >So Program Error is not raised from Initialize - though >on general grounds it may well be best to avoid raising exceptions in >an Initialize. > >Robert I agree that raising exceptions in an Initialize isn't the best way to do things. However, this is the way the application was written for Solaris and I am just porting it to Red Hat Linux. The fact still remains that it appears that the Delay alternative is not working properly in initialize, when compiled with GCC4.3.4. Is there some way to fix this? Compiler switch, pragma, or maybe upgrading compiler (i.e. newer version of GCC or GNATPRO)? Tim