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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ff7d8060c8210f40 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed.icl.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Newsgroups: comp.lang.ada Subject: Re: real_time.clock is not monotonic From: Georg Bauhaus In-Reply-To: <1172074608.834181.198540@j27g2000cwj.googlegroups.com> References: <1172074608.834181.198540@j27g2000cwj.googlegroups.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: # Message-ID: <1172087184.5771.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Date: Wed, 21 Feb 2007 20:46:24 +0100 NNTP-Posting-Date: 21 Feb 2007 20:44:26 CET NNTP-Posting-Host: 635be15c.newsspool2.arcor-online.net X-Trace: DXC=0_aWM7ifQ=kbmW`a1fGWC`2T@AUZfC[5EO0AT8fcn^ X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:9377 Date: 2007-02-21T20:44:26+01:00 List-Id: On Wed, 2007-02-21 at 08:16 -0800, frederic.ormancey@atosorigin.com wrote: > in Linux implementation of Gnat RunTime, Monotonic_Clock is a > single rename of calendar.clock, which use gettimeofday() system > call !!!! > > I'll alert Gnat community with this bad implementation, as > gettimeofday() is affected by NTP and others date adjustements. in > LRM, Ada.Real_Time.Clock shall be monotonic => Gnat runtime is not > compliant What is a possible alternative when making calls to a garden variety Linux kernel? Is there real-time POSIX support in "normal" Linux based systems? > This bug was detected with 3.15p Linux version, but implementation is > still the same with latest source of gnat runtime (s-osprim.adb). > > Did someone have a solution for this problem ? another implementation > using a Linux monotonic clock ?