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 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!news3.google.com!proxad.net!feeder1-2.proxad.net!news.in2p3.fr!in2p3.fr!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Strange behaviour of delay in Windows XP
Date: Sat, 9 Oct 2010 01:42:54 -0500
Organization: Jacob Sparre Andersen
Message-ID: <i8p2tf$cl9$1@munin.nbi.dk>
References: <i8lcl2$f0i$1@news.eternal-september.org>
 <i8lnrd$2mh$1@munin.nbi.dk> <i8mag8$egc$1@news.eternal-september.org>
NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net
X-Trace: munin.nbi.dk 1286606575 12969 69.95.181.76 (9 Oct 2010 06:42:55 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Sat, 9 Oct 2010 06:42:55 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931
Xref: g2news1.google.com comp.lang.ada:14460
Date: 2010-10-09T01:42:54-05:00
List-Id: <comp.lang.ada>

"michael bode" <m.g.bode@web.de> wrote in message 
news:i8mag8$egc$1@news.eternal-september.org...
...
>> 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?

I'd expect that to be compiler-specific. I would guess that many compilers 
would turn it into some form of delay until.

But just calling Sleep in the Win32 API is usually where the problems come 
from; you can't just call it it with any old value because it rounds it up 
to 0.1s. So I could imagine an implementation that for whatever reason 
decided to split up the Sleep calls (maybe to poll something else) could get 
in real trouble. In your case, if it chopped the 1.0s into 270 Sleep calls 
for some reason, you'd get the behavior you see. That could happen if the 
programmer(s) wasn't familar with the oddball behavior of Win32 Sleep.

In Janus/Ada, I had to write code to busy-wait if the delay time is less 
than 0.1s; we only call Sleep if the delay time is longer. (That doesn't 
always work right, either, but I'm not quite sure why.)

                                                   Randy.