By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,364 Members | 1,637 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,364 IT Pros & Developers. It's quick & easy.

infinite loops -- waiting for some event

P: n/a
Hello,
what is the best way of solving cases where one has to wait
(forever, until killed or instructed otherwise) for some event to
occur? E.g., wait for data, monitoring a file? In fact, that task is
not that difficult, but takes over the CPU if the infinite loop
lacks sleep(). I've always thought using this method was somehow
inferior but then found out that even utilities like tail(1) (on
Linux) use it. Or on another occasion, if one uses curses (UNIX
again), which will most likely include an infinite loop, with the
nodelay(...) option turned on. Obviously, there must be a solution to
such cases: with nodelay() turned off, the infinite loop doesn't need
sleep(). Is a daemon, thus a system-dependant solution, the best way
to go or is it unconnected with such a task?

What is the solution behind these methods?

Thanks,

andrej

--
echo ${girl_name} > /etc/dumpdates
Nov 13 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
calling "sleep()" tells the os to schedule a difference task or thread.
which is what you generally want if that task or thread requires some
criteria met before it can continue. otherwise, if you don't call sleep (or
the like), that task or thread will idle needlessly and waste cpu cycles.

-bryan

"Andrej Hocevar" <ah@siol.net> wrote in message
news:sl**************@sonet.utopija.linux...
Hello,
what is the best way of solving cases where one has to wait
(forever, until killed or instructed otherwise) for some event to
occur? E.g., wait for data, monitoring a file? In fact, that task is
not that difficult, but takes over the CPU if the infinite loop
lacks sleep(). I've always thought using this method was somehow
inferior but then found out that even utilities like tail(1) (on
Linux) use it. Or on another occasion, if one uses curses (UNIX
again), which will most likely include an infinite loop, with the
nodelay(...) option turned on. Obviously, there must be a solution to
such cases: with nodelay() turned off, the infinite loop doesn't need
sleep(). Is a daemon, thus a system-dependant solution, the best way
to go or is it unconnected with such a task?

What is the solution behind these methods?

Thanks,

andrej

--
echo ${girl_name} > /etc/dumpdates

Nov 13 '05 #2

P: n/a
On Tue, 15 Jul 2003 13:46:41 GMT, Andrej Hocevar <ah@siol.net> wrote
in comp.lang.c:
Hello,
what is the best way of solving cases where one has to wait
(forever, until killed or instructed otherwise) for some event to
occur? E.g., wait for data, monitoring a file? In fact, that task is
not that difficult, but takes over the CPU if the infinite loop
lacks sleep(). I've always thought using this method was somehow
inferior but then found out that even utilities like tail(1) (on
Linux) use it. Or on another occasion, if one uses curses (UNIX
again), which will most likely include an infinite loop, with the
nodelay(...) option turned on. Obviously, there must be a solution to
such cases: with nodelay() turned off, the infinite loop doesn't need
sleep(). Is a daemon, thus a system-dependant solution, the best way
to go or is it unconnected with such a task?

What is the solution behind these methods?

Thanks,

andrej


The C language has no such facilities. All of the things you are
asking about are non-standard, platform specific extensions. You need
to ask in a group that supports your particular flavor of UNIX, or
news:comp.unix.programmer.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
Nov 13 '05 #3

P: n/a
"Bryan Bullard" <th**********@sbcglobal.net> writes:
calling "sleep()" tells the os to schedule a difference task or thread.
which is what you generally want if that task or thread requires some
criteria met before it can continue. otherwise, if you don't call sleep (or
the like), that task or thread will idle needlessly and waste cpu cycles.


On some systems. The sleep() function is not defined in the C standard.

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 13 '05 #4

P: n/a

"Keith Thompson" <ks*@cts.com> wrote in message
otherwise, if you don't call sleep (or the like), that task or thread will idle needlessly and waste cpu cycles.


On some systems.

What systems can detect busy idling? How do they deal with it?
Nov 13 '05 #5

P: n/a
On Tue, 15 Jul 2003 23:45:06 +0100, in comp.lang.c , "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote:

"Keith Thompson" <ks*@cts.com> wrote in message
> otherwise, if you don't call sleep (or the like), that task or threadwill idle > needlessly and waste cpu cycles.


On some systems.

What systems can detect busy idling? How do they deal with it?


<OT> Most sensible ones, and they deal with it by switching the task
out. After all if its just twiddling its thumbs for 30 secs, then its
sensible to swap it to disk for that time less a bit.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 13 '05 #6

P: n/a
Mark McIntyre <ma**********@spamcop.net> writes:
On Tue, 15 Jul 2003 23:45:06 +0100, in comp.lang.c , "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote:
"Keith Thompson" <ks*@cts.com> wrote in message

> otherwise, if you don't call sleep (or the like), that task or
> thread will idle needlessly and waste cpu cycles.

On some systems.

What systems can detect busy idling? How do they deal with it?


<OT> Most sensible ones, and they deal with it by switching the task
out. After all if its just twiddling its thumbs for 30 secs, then its
sensible to swap it to disk for that time less a bit.


<OT> How can a sensible system tell the difference between a program
"twiddling its thumbs" and doing actual work? If a program contains
something like the following:

for (i = 0; i < SOME_BIG_NUMBER; i ++) {
/* do nothing; this loop should take about 30 seconds */
}

or even

/* non-portably assume that time_t counts seconds */
thirty_seconds_from_now = time() + 30;
while (time() < thirty_seconds_from_now) {
/* do nothing */
}

I'm skeptical that a typical (or any) operating system will be able to
figure out what the program is trying to do and swap it out for 30
seconds. Replacing the /* do nothing */ with some computation makes
this even harder.

(In the first case, of course, the compiler is free to replace the
loop with a single assignment to i, unless i is volatile.)

Or do you mean something else by "busy idling"?

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 13 '05 #7

P: n/a
On Wed, 23 Jul 2003 23:39:06 GMT, in comp.lang.c , Keith Thompson
<ks*@cts.com> wrote:
Mark McIntyre <ma**********@spamcop.net> writes:

<OT> Most sensible ones, and they deal with it by switching the task
out. After all if its just twiddling its thumbs for 30 secs, then its
sensible to swap it to disk for that time less a bit.
<OT> How can a sensible system tell the difference between a program
"twiddling its thumbs" and doing actual work?


With the examples you use, it can't. Thats why you should not use
such methods to attempt to be idle. The OS will provide facilities for
twiddling thumbs.
Or do you mean something else by "busy idling"?


The rest state of programmers when the PHB is not in the room. :-)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 13 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.