From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: "J-P. Rosen" Newsgroups: comp.lang.ada Subject: Re: is there a version of unix written in Ada Date: Thu, 1 Oct 2020 16:18:58 +0200 Organization: Adalog Message-ID: References: <00cd3aaa-d518-43a2-b321-58d6fae70aebo@googlegroups.com> <57eb7a65-51ea-4624-b9dc-9c4dda0fee59n@googlegroups.com> <5f70fd3b$0$13541$426a74cc@news.free.fr> <87wo0d3iac.fsf@nightsong.com> <87sgb02l7b.fsf@nightsong.com> <875z7vyy1u.fsf@nightsong.com> <87wo0bkns3.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Thu, 1 Oct 2020 14:18:56 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="2b758edadbc0032cb464fcdb63eae929"; logging-data="7245"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+BTOZwWHn3voFXb2y4X9CH" User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 Cancel-Lock: sha1:Ofn6tRh/HywUB3fRRioteyjUvZQ= In-Reply-To: Content-Language: fr Xref: reader02.eternal-september.org comp.lang.ada:60363 List-Id: Le 01/10/2020 à 14:51, Dmitry A. Kazakov a écrit : > My mental picture was protected procedure calls executed concurrently on > different cores of a multi-core processor. Would that sort of > implementation be legal? No. Protected objects guarantee that only one task at a time can be inside (ignoring functions). Multi-cores don't come into play. > If so, then let there be protected procedure P1 of the object O1 and P2 > of O2. If P1 and P2 call to P3 of O3 that would be a problem. Ergo ether > wandering or concurrent protected protected calls must be illegal. But it's not the case... >> 1. A LIFO queue of log entries implemented in a protected object of >> highest priority. The object has a procedure "Write_Log_Entry". > > Yes, that was what I thought and what Debug.adb does. However Debug.adb > allocates the body of the FIFO element in the pool. I would rather use > my implementation of indefinite FIFO which does not use pools. I don't > want allocators/deallocators inside protected stuff. As surprising as it may seem, allocators/deallocators are NOT potentially blocking operations. But I understand your concerns... >> 2. A task that empties the LIFO queue into a log file. The task calls >> an entry of the LIFO protected object to get a log entry from the >> queue, but executes the file-writing operations in task context, not >> in a protected operation. > > A simpler approach is to flush the queue by the first call to an > unprotected variant of Trace. I believe Debug.adb does just this. Yes. Moreover, there is a Finalize of a controlled object to make sure that no trace is lost if the program terminates without calling any (unprotected) Trace. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr