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: 103376,ee06257af909a235 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news1.google.com!news.glorb.com!wns14feed!worldnet.att.net!attbi_s21.POSTED!53ab2750!not-for-mail From: "Jeffrey R. Carter" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Finalization of static package variables References: <4640f20b$1@news.upm.es> <1178723724.958486.24820@u30g2000hsc.googlegroups.com> <464244d8$1@news.upm.es> <1178753228.648765.89390@e65g2000hsc.googlegroups.com> In-Reply-To: <1178753228.648765.89390@e65g2000hsc.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 12.201.97.213 X-Complaints-To: abuse@mchsi.com X-Trace: attbi_s21 1178772744 12.201.97.213 (Thu, 10 May 2007 04:52:24 GMT) NNTP-Posting-Date: Thu, 10 May 2007 04:52:24 GMT Organization: AT&T ASP.att.net Date: Thu, 10 May 2007 04:52:24 GMT Xref: g2news1.google.com comp.lang.ada:15704 Date: 2007-05-10T04:52:24+00:00 List-Id: Adam Beneschan wrote: > > Maybe. I don't know anything about JEWL, so I don't know what the > declaration of "Frame_Type" is or what the "Frame" function does. But > if the Frame function uses an allocator to create an access-to-task, > and if Frame_Type is a controlled type (or has controlled components) > whose Finalize routine does something that terminates that task, then > I can see how you would have a problem. According to 9.3, if you (or > some routine in JEWL) have started a task with an allocator, then that > task depends on the master that elaborates the access-to-task *type* > (and any enclosing master). Assuming the access type is declared at > the library level somewhere inside JEWL, then the only master it > depends on is the environment task. The task in JEWL is a singleton task declared in the specification of a library-level private package. This task keeps track of how many frames have been created and doesn't end until they've all been destroyed. The frame in the subprogram is destroyed when it is finalized when the subprogram returns; the frame in the package won't be finalized until the task ends. With the frame in a subprogram, the call to Close isn't strictly necessary (though it's a good idea). With the frame in the package, the call to Close is necessary. Otherwise, the task won't end until the frame is finalized, and the frame won't be finalized until the task ends. -- Jeff Carter "C++ is like giving an AK-47 to a monk, shooting him full of crack and letting him loose in a mall and expecting him to balance your checking account 'when he has the time.'" Drew Olbrich 52