Dears,
=A0 =A0 I'm writing C application using native compiler /usr/bin/c89 to
run under OSS environment or linux. I would like to implement delay
in
milliseconds. Does anyone know what is the best way to do this?

Thanks in advance.

In article <0413b115-8220-4633-b48a-
8eb41a681cac@l14g2000yqb.googlegroups.com>, ashraf.fouad@gmail.com 
says...
> 
> Dears,
> � � I'm writing C application using native compiler /usr/bin/c89 to
> run under OSS environment or linux. I would like to implement delay
> in
> milliseconds. Does anyone know what is the best way to do this?

From the C-FAQ:

19.37:	How can I implement a delay, or time a user's response,
	with sub-second resolution?

A:	Unfortunately, there is no portable way.  Routines you might
	look for on your system include clock(), delay(), ftime(),
	gettimeofday(), msleep(), nap(), napms(), nanosleep(),
	setitimer(), sleep(), Sleep(), times(), and usleep().
	(A function called wait(), however, is at least under Unix *not*
	what you want.)  The select() and poll() calls (if available)
	can be pressed into service to implement simple delays.
	On MS-DOS machines, it is possible to reprogram the system timer
	and timer interrupts.

	Of these, only clock() is part of the ANSI Standard.  The
	difference between two calls to clock() gives elapsed execution
	time, and may even have subsecond resolution, if CLOCKS_PER_SEC
	is greater than 1.  However, clock() gives elapsed processor
	time used by the current program, which on a multitasking system
	may differ considerably from real time.

	If you're trying to implement a delay and all you have available
	is a time-reporting function, you can implement a CPU-intensive
	busy-wait, but this is only an option on a single-user, single-
	tasking machine, as it is terribly antisocial to any other
	processes.  Under a multitasking operating system, be sure to
	use a call which puts your process to sleep for the duration,
	such as sleep() or select(), or pause() in conjunction with
	alarm() or setitimer().

	For really brief delays, it's tempting to use a do-nothing loop
	like

		long int i;
		for(i = 0; i < 1000000; i++)
			;

	but resist this temptation if at all possible!  For one thing,
	your carefully-calculated delay loops will stop working properly
	next month when a faster processor comes out.  Perhaps worse, a
	clever compiler may notice that the loop does nothing and
	optimize it away completely.

	References: H&S Sec. 18.1 pp. 398-9; PCS Sec. 12 pp.
	197-8,215-6; POSIX Sec. 4.5.2.

"Dann Corbit" <dcorbit@connx.com> wrote in message 
news:MPG.271d06b866a1218b989747@news.eternal-september.org...
> In article <0413b115-8220-4633-b48a-
> 8eb41a681cac@l14g2000yqb.googlegroups.com>, ashraf.fouad@gmail.com
> says...

> For really brief delays, it's tempting to use a do-nothing loop
> like
>
> long int i;
> for(i = 0; i < 1000000; i++)
> ;

An optimizing compiler may remove the loop.  Make i volatile or have the 
loop do something interesting in the loop.

In article <i8vnfj$v4k$1@usenet01.boi.hp.com>, fred.nospam@dec.com 
says...
> 
> "Dann Corbit" <dcorbit@connx.com> wrote in message 
> news:MPG.271d06b866a1218b989747@news.eternal-september.org...
> > In article <0413b115-8220-4633-b48a-
> > 8eb41a681cac@l14g2000yqb.googlegroups.com>, ashraf.fouad@gmail.com
> > says...
> 
> > For really brief delays, it's tempting to use a do-nothing loop
> > like
> >
> > long int i;
> > for(i = 0; i < 1000000; i++)
> > ;
> 
> An optimizing compiler may remove the loop.  Make i volatile or have the 
> loop do something interesting in the loop.

It is always good to read the message before responding.

FredK <fred.nospam@dec.com> wrote:
> "Dann Corbit" <dcorbit@connx.com> wrote in message 
> news:MPG.271d06b866a1218b989747@news.eternal-september.org...
> > In article <0413b115-8220-4633-b48a-
> > 8eb41a681cac@l14g2000yqb.googlegroups.com>, ashraf.fouad@gmail.com
> > says...

> > For really brief delays, it's tempting to use a do-nothing loop
> > like
> >
> > long int i;
> > for(i = 0; i < 1000000; i++)
> > ;

> An optimizing compiler may remove the loop.  Make i volatile or have the 
> loop do something interesting in the loop.

But that doesn't address the second problem mentioned in the FAQ,
i.e. that the execution time and thus the delay achieved still
depends on the hardware this is running on. So using a proper
system-specific function (like the ones listed in the FAQ, e.g.
nanosleep() on POSIX systems, Sleep() under Windows etc.) is
probably a safer bet.
                              Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

On 2010-10-11, Ashraf Fouad <ashraf.fouad@gmail.com> wrote:
> Dears,
> ? ? I'm writing C application using native compiler /usr/bin/c89 to
> run under OSS environment or linux. I would like to implement delay
> in
> milliseconds. Does anyone know what is the best way to do this?

Many people know!  They know the best ways to do it in various different
contexts.

Long story short:  There is not a particularly "best" generic C way to do
this.  There are many exceptionally bad ways.  Most specific real environments
will provide a reasonably good way to do this, or possibly several reasonably
good ways to do this.  A real answer depends on the environment you're
in.

It sounds like Linuxy stuff, but "OSS environment or linux" is confusing,
and the Linux systems I use have not usually considered anything called
"c89" to be the "native compiler".  If you're looking for something that works
on user-mode code on a Unix system, try comp.unix.programmer.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

"FredK" <fred.nospam@dec.com> writes:
> "Dann Corbit" <dcorbit@connx.com> wrote in message 
> news:MPG.271d06b866a1218b989747@news.eternal-september.org...
>> In article <0413b115-8220-4633-b48a-
>> 8eb41a681cac@l14g2000yqb.googlegroups.com>, ashraf.fouad@gmail.com
>> says...
>
>> For really brief delays, it's tempting to use a do-nothing loop
>> like
>>
>> long int i;
>> for(i = 0; i < 1000000; i++)
>> ;
>
> An optimizing compiler may remove the loop.  Make i volatile or have the 
> loop do something interesting in the loop.

Your suggesting an improvement for a technique that almost certainly
shouldn't be used in the first place.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Seebs <usenet-nospam@seebs.net> writes:
[...]
> It sounds like Linuxy stuff, but "OSS environment or linux" is confusing,
> and the Linux systems I use have not usually considered anything called
> "c89" to be the "native compiler".  If you're looking for something that works
> on user-mode code on a Unix system, try comp.unix.programmer.

On my system (Ubuntu 9.04), "c89" is essentially a wrapper for
"gcc -std=c89".  There's a similar "c99" which is a wrapper for
"gcc -std=c99".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

In article <lnpqvglaj4.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
>"FredK" <fred.nospam@dec.com> writes:
>> "Dann Corbit" <dcorbit@connx.com> wrote in message 
>> news:MPG.271d06b866a1218b989747@news.eternal-september.org...
>>> In article <0413b115-8220-4633-b48a-
>>> 8eb41a681cac@l14g2000yqb.googlegroups.com>, ashraf.fouad@gmail.com
>>> says...
>>
>>> For really brief delays, it's tempting to use a do-nothing loop
>>> like
>>>
>>> long int i;
>>> for(i = 0; i < 1000000; i++)
>>> ;
>>
>> An optimizing compiler may remove the loop.  Make i volatile or have the 
>> loop do something interesting in the loop.
>
>Your suggesting an improvement for a technique that almost certainly
>shouldn't be used in the first place.

Aren't you even going to point out the obvious fact - that the code
above is the only standards compliant way to do it (*) and thus *is* the
CLC-recommended way to do it.

(*) With, of course, the volatile declaration - can't forget that, Oh no.

-- 
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...

In article <lnhbgsl7i3.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
>Seebs <usenet-nospam@seebs.net> writes:
>[...]
>> It sounds like Linuxy stuff, but "OSS environment or linux" is confusing,
>> and the Linux systems I use have not usually considered anything called
>> "c89" to be the "native compiler".  If you're looking for something that works
>> on user-mode code on a Unix system, try comp.unix.programmer.
>
>On my system (Ubuntu 9.04), "c89" is essentially a wrapper for
>"gcc -std=c89".  There's a similar "c99" which is a wrapper for
>"gcc -std=c99".

POSIX requires a program called "c99", which "shall accept source code
conforming to the ISO C standard." For GNU/Linux distributors, the easiest
way to comply is with that wrapper script which calls gcc -std=c99.

c89 is the same concept from an earlier POSIX version.

For some reason, good old "cc" is not required to exist, even though the
specification for c99 is basically "have options like a traditional unix cc"

-- 
Alan Curry

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnpqvglaj4.fsf@nuthaus.mib.org...
> "FredK" <fred.nospam@dec.com> writes:
>> "Dann Corbit" <dcorbit@connx.com> wrote in message
>> news:MPG.271d06b866a1218b989747@news.eternal-september.org...
>>> In article <0413b115-8220-4633-b48a-
>>> 8eb41a681cac@l14g2000yqb.googlegroups.com>, ashraf.fouad@gmail.com
>>> says...
>>
>>> For really brief delays, it's tempting to use a do-nothing loop
>>> like
>>>
>>> long int i;
>>> for(i = 0; i < 1000000; i++)
>>> ;
>>
>> An optimizing compiler may remove the loop.  Make i volatile or have the
>> loop do something interesting in the loop.
>
> Your suggesting an improvement for a technique that almost certainly
> shouldn't be used in the first place.
>

The unfortunate truth is that I have indeed been in situations where there 
were indeed few good choices, including spinning on the HW clock.  However, 
all I did was note that any reasonable level of optimization would turn this 
into (at best) i = 1000000;

"FredK" <fred.nospam@dec.com> writes:

> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnpqvglaj4.fsf@nuthaus.mib.org...
>> "FredK" <fred.nospam@dec.com> writes:
>>> "Dann Corbit" <dcorbit@connx.com> wrote in message
>>> news:MPG.271d06b866a1218b989747@news.eternal-september.org...
>>>> In article <0413b115-8220-4633-b48a-
>>>> 8eb41a681cac@l14g2000yqb.googlegroups.com>, ashraf.fouad@gmail.com
>>>> says...
>>>
>>>> For really brief delays, it's tempting to use a do-nothing loop
>>>> like
>>>>
>>>> long int i;
>>>> for(i = 0; i < 1000000; i++)
>>>> ;
>>>
>>> An optimizing compiler may remove the loop.  Make i volatile or have the
>>> loop do something interesting in the loop.
>>
>> Your suggesting an improvement for a technique that almost certainly
>> shouldn't be used in the first place.
>>
>
> The unfortunate truth is that I have indeed been in situations where there 
> were indeed few good choices, including spinning on the HW clock.  However, 
> all I did was note that any reasonable level of optimization would turn this 
> into (at best) i = 1000000;

Yes, but to give you space to write this you snipped the bit from the
quoted FAQ that had already said that!
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

Seebs wrote:
> On 2010-10-11, Ashraf Fouad <ashraf.fouad@gmail.com> wrote:
>> Dears,
>> ? ? I'm writing C application using native compiler /usr/bin/c89 to
>> run under OSS environment or linux. I would like to implement delay
>> in
<snip>
> It sounds like Linuxy stuff, but "OSS environment or linux" is
> confusing,

OSS here means "Open Software Services", the POSIX personality of HP NonStop 
Kernel (formerly Tandem)

> and the Linux systems I use have not usually considered anything
> called "c89" to be the "native compiler".

It is called that way on OSS, as opposed to the non-native compiler for the 
older home made CISC architecture Tandem used in the old days, but still 
available on the newer MIPS and and to some extent on the latest Itanium 
architecures.

>If you're looking for something that works
>on user-mode code on a Unix system, try comp.unix.programmer.

Or, in fact, in comp.sys.tandem (which he did)

bye, Jojo

On 10/11/2010 3:31 PM, Ashraf Fouad wrote:
> Dears,
>      I'm writing C application using native compiler /usr/bin/c89 to
> run under OSS environment or linux. I would like to implement delay
> in milliseconds. Does anyone know what is the best way to do this?

There isn't any portable way to do this in standard C.  However, I believe 
that POSIX defines usleep(), which takes a time in microseconds.

-- 
Kenneth Brody

On Tue, 12 Oct 2010 13:35:42 -0400, Kenneth Brody wrote:

> There isn't any portable way to do this in standard C.  However, I believe 
> that POSIX defines usleep(), which takes a time in microseconds.

POSIX /used/ to define usleep(). It was declared obsolete in POSIX.1-2001
in favour of nanosleep(). It was removed in POSIX.1-2008.