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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,cae92f92d6a1d4b1 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder2.cambriumusenet.nl!feed.tweaknews.nl!87.79.20.105.MISMATCH!news.netcologne.de!ramfeed1.netcologne.de!news.tele.dk!feed118.news.tele.dk!news.tele.dk!small.news.tele.dk!bnewspeer01.bru.ops.eu.uu.net!bnewspeer00.bru.ops.eu.uu.net!emea.uu.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Ada.Execution_Time Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <4d05e737$0$6980$9b4e6d93@newsspool4.arcor-online.net> <1wmsukf0wglz3$.odnzonrpayly.dlg@40tude.net> <6n1c5myuf2uz$.10jl3ln7il3aq.dlg@40tude.net> <8n0mgnFv2sU1@mid.individual.net> <1n3o55xjdjr9t.1u33kb75y2jfl$.dlg@40tude.net> <8n1142Fto2U1@mid.individual.net> <1o5cbm4b1l20d$.19winbma6k5qw.dlg@40tude.net> <8n4mskF7mmU1@mid.individual.net> <8nm30fF7r9U1@mid.individual.net> <8o0p0lF94rU1@mid.individual.net> Date: Wed, 29 Dec 2010 17:51:15 +0100 Message-ID: NNTP-Posting-Date: 29 Dec 2010 17:51:14 CET NNTP-Posting-Host: 532b1751.newsspool2.arcor-online.net X-Trace: DXC=b2_XC[FlnhSYI9]OHn9o5^A9EHlD;3YcR4Fo<]lROoRQ8kF On Wed, 29 Dec 2010 16:19:13 +0000, (see below) wrote: > From this I deduce that the intent for CPU_Time is that it be a useful > approximation to the sum of the durations (small "d") of the intervals of > local inertial-frame physical time in which the task is in the running > state. There exist more pragmatic considerations than the relativity theory. The duration you refer above is according to which clock? - Real time CPU counter - Programmable timer - BIOS clock - OS system clock - Ada.Real_Time.Clock - Ada.Calendar.Clock - an NTP server from the given list ... ... > It seems to me that the only grey area is the degree of approximation that > is acceptable for the result to be "useful". That is the next can of worms to open. Once you decided which clock you take, you would have to define the sum of *which* durations according to this clock you are going to approximate. This would be way more difficult and IMO impossible. What is the "CPU" is presence of many cores? What does it mean for the task to be "active" keeping in mind the cases it could get blocked without losing the "CPU" (defined above)? In my humble opinion, ARG defined Ada.Execution_Time in the most *reasonable* way, in particular, allowing to deliver whatever garbage the underlying OS service spits. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de