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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!NADC.ARPA!prindle From: prindle@NADC.ARPA (Frank Prindle) Newsgroups: comp.lang.ada Subject: Deallocation of T'STORAGE_SIZE for a terminated task Message-ID: <8809211336.AA02004@NADC.ARPA> Date: 21 Sep 88 13:36:45 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet List-Id: Given: 1. An allocator may be used with a task type to dynamically activate a task as a consequence of 9.3(6). The run-time system reserves 'STORAGE_SIZE storage units for use by this activation as stated in 13.7.2(14). 2. The task thus activated may eventually become completed and terminate as a consequence of 9.4(5,6). 3. The task object allocated is considered inaccessible once the task has terminated as a consequence of 4.8(7). 4. An implementation may (but need not) reclaim the storage reserved for the task object once it has terminated, as stated in 4.8(7). 5. Automatic deallocation, when available, may be selectively inhibited via pragma CONTROLLED as a consequence of 4.8(10). 6. Explicit deallocation of storage reserved for a dynamically allocated object is provided by instantiation of UNCHECKED_DEALLOCATION, as stated in 4.8(12). 7. An instantiation of UNCHECKED_DEALLOCATION for a task object is guaranteed to have ***NO*** effect on the task designated by the task object by 13.10.1(8)! Then: If an implementation does not provide for automatic storage deallocation, what mechanism allows the repeated execution of dynamically activated tasks without eventual consumption of the entire heap (or that partition reserved for task objects) and the subsequent irrecoverable STORAGE_ERROR? Notice that everything made sense up through point 6 above. The implication was that one could not rely on an implementation to reclaim dynamically allocated storage at the appropriate time, and should always explicitly deallocate every object explicitly allocated (once it has been determined that the object is no longer required). It is further implied that a simple test of the 'TERMINATED attribute of the task object would suffice to determine when a task object (i.e. the stack for use by a task activation) is no longer required. The killer is 7 above. When 13.10.1(8) says "no effect on the task", does this imply that the storage is not to be deallocated? But that is the very job intended to be performed by this generic library procedure, as stated in 4.8(12)! I think we need a clarification of 13.10.1(8) here, because at least one implementation has taken it to mean that the storage cannot be deallocated. Therefore, dynamic activation of transient tasks (i.e. tasks which will eventually terminate on their own) appears to be a lost cause. It is quite possible that yet another section of the LRM clarifies this question, but the index leads me only in an endless circle of the paragraphs cited above. Any pointers would be warmly welcomed. Sincerely, Frank Prindle Prindle@NADC.arpa