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.4 required=5.0 tests=BAYES_00,SUBJ_ALL_CAPS autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,51359402da60c472 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-18 23:05:56 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!wn12feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!sccrnsc04.POSTED!not-for-mail Message-ID: <3EF15295.5020307@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: DYNAMIC ADA TASK CREATION? References: <3EF0026E.2050309@attbi.com> <3ef04842.436197@news.btclick.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.62.164.137 X-Complaints-To: abuse@attbi.com X-Trace: sccrnsc04 1056002749 24.62.164.137 (Thu, 19 Jun 2003 06:05:49 GMT) NNTP-Posting-Date: Thu, 19 Jun 2003 06:05:49 GMT Organization: AT&T Broadband Date: Thu, 19 Jun 2003 06:05:49 GMT Xref: archiver1.google.com comp.lang.ada:39430 Date: 2003-06-19T06:05:49+00:00 List-Id: Simon Wright wrote: >>>: type ts is array (positive range <>) of ta := new t; >>> ^^^^^^^^ > That version was Robert's ... Let me make it official, it was a typo, should have been: type ts is array (positive range <>) of ta := (others => new t); But I really wanted to answer this: Oh, why is it worse with discriminants? There are usually in Ada implementations two types of storage associated with tasks. The first is a task descriptor, which contains addresses for the code, entry queues, and other such stuff. The other part is a stack and (and possibly local heap) for the executing object. If the task has descriminants, they are normally stored in the task descriptor. Again in the normal case, the stack (and local heap if allocated) will be deallocated when the task terminates. The task descriptor is the thing that can be deallocated by Unchecked_Deallocation. If a task without discriminants is freed before it becomes terminated, it won't affect the executing task. But it may deallocate the task descriptor which contains the discriminants. If the task, or any of it's dependent tasks references the discriminants, it is a bounded error, which will most likely cause Program_Error in the task. See RM 13.11.2(11-15) for details on other possibilities. For a task without discriminants, you may not free all the memory that you had hoped for, but the only real effect is that you may no longer be able to reference the task. (Of course, calling an instance of Unchecked_Deallocation while salting away a copy of the pointer is not something you should do either. But that case is a lot more obvious.) In most normal tasking programs there is no particular reason to free the task descriptors. And as I said, the memory allocated for the stack will go away anyway when the task is terminated. (In language lawyer speak, a task is completed when the code execution reaches the end of the code and in other cases. But termination waits until all dependent tasks have become terminated. This is so that dependent tasks can still reference the parent task's stack.) So usually when a programmer thinks he wants to go around stomping out tasks, he has left one or two tasks hanging that are keeping a lot of other tasks half-alive.