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,349427c451f66022
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news1.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nntp.club.cc.cmu.edu!feeder.erje.net!newsfeed.datemas.de!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: michael bode <m.g.bode@web.de>
Newsgroups: comp.lang.ada
Subject: Re: Strange behaviour of delay in Windows XP
Date: Fri, 08 Oct 2010 07:33:59 +0200
Organization: A noiseless patient Spider
Message-ID: <i8mag8$egc$1@news.eternal-september.org>
References: <i8lcl2$f0i$1@news.eternal-september.org>
 <i8lnrd$2mh$1@munin.nbi.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 8 Oct 2010 05:34:00 +0000 (UTC)
Injection-Info: mx03.eternal-september.org;
 posting-host="Fmek1ch0Wr3fNUwTvw+eHg";
	logging-data="14860"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19xoupuu8Bu2MtcxdTM1Bgu01TkxuCRHZw="
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8
In-Reply-To: <i8lnrd$2mh$1@munin.nbi.dk>
Cancel-Lock: sha1:2Yk1/1E2jS3SZibPiJZKf1posfw=
Xref: g2news1.google.com comp.lang.ada:14431
Date: 2010-10-08T07:33:59+02:00
List-Id: <comp.lang.ada>

Am 08.10.2010 02:15, schrieb Randy Brukardt:

> I have no ideas about your specific problem, but we found when building Claw 
> that delays were quite unreliable on Windows. One compiler insisted on 
> delaying a full clock tick (0.1s) even for "delay 0.0;" (used to mean 
> "yield"; Ada 2012 will actually have a call named "yield") -- this was a 
> disaster as we were using it in the primary message loop (adding 0.1s per 
> message slowed apps to a crawl). All were inaccurate to some extent or 
> another. All were improved to some extent or another after we filed bug 
> reports.

I wouldn't complain about one clock tick or 100ms. But 1700ms is really
too much.

> It wouldn't be hard to do something in an implementation of "delay" that 
> caused a time explosion in some case or another.

Does a relative delay do more than call something like usleep(3) or
whatever is the corresponding Win32 API?