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=-3.2 required=3.0 tests=BAYES_00,NICE_REPLY_A, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: =?UTF-8?Q?Bj=c3=b6rn_Lundin?= Newsgroups: comp.lang.ada Subject: Re: Freeing access-to-task objects Date: Sat, 1 Oct 2022 23:26:31 +0200 Organization: A noiseless patient Spider Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 1 Oct 2022 21:26:32 -0000 (UTC) Injection-Info: reader01.eternal-september.org; posting-host="83e97341c406278d0319cf1b63587d90"; logging-data="1507690"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18G6zGmW12raa6hcLHf7YU9" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Cancel-Lock: sha1:JW9MMMtBp8XIag8XN+j3vcpz4QA= In-Reply-To: Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:64474 List-Id: On 2022-10-01 13:58, Dmitry A. Kazakov wrote: > 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. > I agree, in practice it works very well, at least for our system. When ported to GNAT in 2003 I used this pattern. We use it in IPC, where main makes a blocking call to a PO, looking for incoming messages. The PO is protecting a list, and main blocks on list_count = 0. Another task (receive task) in the IPC body blocks on a read call from a named pipe. When a message arrives in the pipe, this task is putting it into the PO's list. Main then unblocks, since list_count >0, gets the message and treats it, But since the receiver task is blocking as well, it is difficult to make that call timeout. Sometimes we want main to actually block until a message arrives, but sometimes we'd like to timeout after a minute or so. Main can call the receive procedure with or without a timeout. If time is used in the call, a third task is started - with new - with a timeout time, and a 'stop' entry. This timer task just delays timeout time, and writes a timeout message to the pipe when expired - thus releasing the blocking task, and also releasing main since a timeout message was put in PO's list and list_count becomes > 0. If a message is put by another process in the pipe, the receiving task calls stop on the timer task, removes any timeout messages in the list if we had a race, and puts the message in the list. Here we also loop over the timer task until terminated. Worked very well for many years in many installations We do send messages frequently. in bursts up to 100 msgs/s but average is less likely than 10 msgs/s 1_000_000 msgs/day is not unusual, so memleaks here is a problem -- /Björn