From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader01.eternal-september.org!aioe.org!UAyUbOgXzVgfYRW/bLvE8Q.user.46.165.242.91.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Freeing access-to-task objects Date: Sat, 1 Oct 2022 13:58:37 +0200 Organization: Aioe.org NNTP Server Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: gioia.aioe.org; logging-data="9079"; posting-host="UAyUbOgXzVgfYRW/bLvE8Q.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org"; User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:64471 List-Id: On 2022-10-01 13:40, J-P. Rosen wrote: > Le 30/09/2022 à 12:16, Emmanuel Briot a écrit : >> Please find a new blog post at: >> >> https://deepbluecap.com/freeing-task-access-objects/ >> >> Abstract: >> Freeing Ada tasks could result in accessing freed memory. This post >> describes the proper way of freeing access-to-task objects. > > I don't like an active loop to wait for task termination. IMO, it is the best method. > There are > other ways: > 1) declare the access type in a block, which is then the master of the > tasks. When you exit the block, the tasks are terminated. That is usually not possible, or if possible, then the task object itself can be in the block and no access type needed at all. Almost all cases when access to task is used is due to language design flaw not allowing either usable aggregation of task objects or inheritance involving tasks. > 2) declare in the tasks an entry which is never accepted, then call this > entry from the main. When the task terminates, it raises tasking_error > in the (unserved) callers - you can free the task from the exception > handler. This is uglier than a loop. However I must admit that it should have advantage in terms of performance, both CPU load and latency. A disadvantage is that you cannot wait for several tasks that way. In a production code there is a timeout which limits the overall waiting time and sometimes multiple tasks are awaited to terminate. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de