Sleeping or waiting

[Blue Ocean]

Is there any platform independent way to make a C program wait for a
certain amount of time before performing a task? I don't mean:

while(difftime(clock1, clock()) < MAGICNUMBER);

Rather, I want something that cuts down on a program's use of
processor time when it is executing, like Java's Thread.sleep(int
milliseconds) method. Currently, whenever I write programs, they take
up 50% of my processor exactly (since I have a hyperthreading
processor, the maximum any one thread can use is fifty percent, or so
I've been lead to believe). I would like to make it so that the
program takes a step every, say, 1/60th of a second, for a physics
simulation, but I would like any spare processor time to revert to the
system idle thread.

 

[jacob navia]

Unix has
#include <unixstd.h>
unsigned int sleep(int seconds);

Windows has

#include <windows.h>
void Sleep(unsigned long miliseconds);

and most OSes provide the same functionality.

Look at the documentation of your system.

 

[jacob navia]

Unix has
#include <unixstd.h>
unsigned int sleep(int seconds);

Sorry, the "seconds" argument should be unsigned int.

 

[Martin Ambuhl]

Is there any platform independent way to make a C program wait for a
certain amount of time before performing a task?

No. Such things are inherently OS-dependent.

 

[Keith Thompson]

Is there any platform independent way to make a C program wait for a
certain amount of time before performing a task? I don't mean:

while(difftime(clock1, clock()) < MAGICNUMBER);

Rather, I want something that cuts down on a program's use of
processor time when it is executing

[...]

No, there's no platform independent way of doing this. There should
be platform dependent ways of doing it on almost all platforms; for
something like this, #ifdef is your friend.

 

[Arto Huusko]

Sorry, the "seconds" argument should be unsigned int.

And the header should be #include <unistd.h>

 

[Eric Enright]

And the header should be #include <unistd.h>

Sorry for the OT, but since someone mentioned it..
Is "unistd" some sort of abbreviation for "unix standard" ?
I've always been curious about that header filename, and the
above seems to make sense, especially after discovering (and
subsequently reading) The Open Group's manpage for it.

If so, would anyone by chance know why the 'x' was omitted?

 

[Dan Pop]

Sorry for the OT, but since someone mentioned it..
Is "unistd" some sort of abbreviation for "unix standard" ?

Sort of.

I've always been curious about that header filename, and the
above seems to make sense, especially after discovering (and
subsequently reading) The Open Group's manpage for it.

If so, would anyone by chance know why the 'x' was omitted?

Have a close look at all the C89 standard header names. The same
reason applied, apparently, in the case of <unistd.h>, too.

Dan

 

[Eric Enright]

Sort of.


Have a close look at all the C89 standard header names. The same
reason applied, apparently, in the case of <unistd.h>, too.

Indeed, I see the similar naming convention.
Thanks for the pointer.

 

[Dan Pop]

Indeed, I see the similar naming convention.

It's not the similar naming convention, it's the fact that no standard
header name exceeds 8 characters (the .h suffix included). unixstd.h
would take 9 characters. The care for not exceeding the 8 character limit
is obvious, as stddef.h and stdarg.h would have looked better with an s
at the end (before the suffix).

This implicit 8 character limit is gone in C99, where one can find
something as wide as inttypes.h.

Dan

 

[Keith Thompson]

It's not the similar naming convention, it's the fact that no standard
header name exceeds 8 characters (the .h suffix included). unixstd.h
would take 9 characters. The care for not exceeding the 8 character limit
is obvious, as stddef.h and stdarg.h would have looked better with an s
at the end (before the suffix).

This implicit 8 character limit is gone in C99, where one can find
something as wide as inttypes.h.

Actually, the 8 character limit is explicit.

C90 6.8.2 (Source file inclusion) says:

There shall be an implementation-defined mapping between the
delimited sequence and the external source file name. The
implementation shall provide unique mappings for sequences
consisting of one or more letters (as defined in 5.2.1) followed
by a period (.) and a single letter. The implementation may
ignore the distinctions of alphabetical case and restrict the
mapping to six significant characters before the period.

There may have been some wiggle room here, since "#include <stddef.h>"
specifies a header but not necessarily a file, but the authors of the
standard wisely didn't take advantage of that.

C99 (6.10.2p5) increases the limit to eight significant characters
before the period.

(I vaguely recall that some old IBM mainframe operating systems
limited file names to 6 characters.)

 

[Eric Enright]

It's not the similar naming convention, it's the fact that no standard
header name exceeds 8 characters (the .h suffix included). unixstd.h
would take 9 characters. The care for not exceeding the 8 character limit
is obvious, as stddef.h and stdarg.h would have looked better with an s
at the end (before the suffix).

Thanks Dan, that is most interesting! It seems I am too
accustomed to long file names, and forget that not all systems
have them.

All this has me very interested now..
I think I'm going to walk over to my college, hopefully the
library has a copy of C89. Otherwise I'll investigate the
drafts/etc posted by you and others in a recent thread more
thoroughly.

 

[kal]

It's not the similar naming convention, it's the fact that no standard
header name exceeds 8 characters (the .h suffix included). unixstd.h
would take 9 characters. The care for not exceeding the 8 character limit
is obvious, as stddef.h and stdarg.h would have looked better with an s
at the end (before the suffix).

This implicit 8 character limit is gone in C99, where one can find
something as wide as inttypes.h.

I think it is more of a 6 + 2 than 8. That is, the part
before the period was limited to six characters.
The reasons are probably historical.

I may be wrong but isn't or wasn't there a limitation that
"external" names are significant in the first 6 characters
only?

<OT>
Why six charactres? you might ask. It is for the same reason
that the Lord created everything in six days. That is to say,
six is the smallest perfect number.
NOT.
</OT>

 

[Dan Pop]

(I vaguely recall that some old IBM mainframe operating systems
limited file names to 6 characters.)

I clearly recall RT-11 limiting file names to 6 characters (plus 3 for
the extension).

Dan

 

[Dan Pop]

<OT>
Why six charactres? you might ask. It is for the same reason
that the Lord created everything in six days. That is to say,
six is the smallest perfect number.
NOT.
</OT>

There are two main historical reasons for 6.

1. Old 36-bit machines, using 6-bit character sets. One machine word
can represent six characters. This is, most likely, where old
FORTRAN versions got their 6-character limit for all identifiers from.

2. The DEC PDP-11, a very important architecture of the seventies. The
DEC operating systems for the PDP-11 used, in many contexts, including
linker symbols and file names, a character set consisting of 40
characters (RADIX-50) with an associated encoding scheme that was
packing 3 characters in a 16-bit machine word. Two words could
represent a linker symbol or an RT-11 file name. Three words could
represent an RSX-11 file name and one word could represent a 3-letter
extension for all DEC operating systems for the PDP-11.

Dan

 

[kal]

There are two main historical reasons for 6.

Thank you, Mr. Pop. I figured there were some mundane
explanations like that. A few more explanations like
this and you will take the romance out of programming.

<OT>
That bit about perfect numbers was a lagniappe. I do
like it better though. Among other things, it explains
why life is based on carbon.
</OT>