|
Re: infinite loops == bad?
by rbc (Curate) on Apr 23, 2002 at 20:07 UTC
|
The Camel Book has a interesting comment about
infinite loops. " ... if your writing the code
to control a cruise missle, you may not actually need
to write a loop exit. The loop will be terminated
automatically at the appropriate moment*"
:))) | [reply] |
Re: infinite loops == bad?
by thelenm (Vicar) on Apr 23, 2002 at 20:10 UTC
|
Infinite loops aren't "bad". Infinite loops that do nothing useful and hog resources are bad. Many of the programs we use all the time are "infinite loops": your operating system, the shell, daemons, your web browser, ... infinite loops are not inherently bad, but you must take care when writing one since they have the potential to eat resources very quickly (or slowly :-). | [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in. |
Re: infinite loops == bad?
by broquaint (Abbot) on Apr 23, 2002 at 21:45 UTC
|
Infinite loops (a loop with an unconditionally true condition) are generally bad, and should be re-structured as potentially infinite loops. A well written server that relies on a loop as it's main form of receiving input should have a situation in which it's loop condition can be negated, thereby exitting the loop. This will allow for cleanup and shutdown of any periphery functions it's performing. A good example would be a simple HTTP server where the condition of the loop would be the output from a blocking socket, so if for whatever reason the socket is closed, it can clean up (i.e close log file handles) and possibly notify the administrator.
I can't think of any conditions in where you would need an infinitely running loop (any offers?) so I'd say that in theory they are a bad thing. It's also considered bad practice to have 'busy-wait loops'[1] when working with IO as you should generally be waiting for input to come instead of deliberately putting delays within the loop. One reason is that you *might* (just might) receive a shedload of data while sleeping away which could potentially break things within (and without) the program (i.e stack overflow).
HTH
_________
broquaint
[1] a busy-wait loop is one which has specified delays within the program e.g while(<FOO>) { &do_stuff($_); sleep 5; }. More details here | [reply]
[d/l] |
Re: infinite loops == bad?
by Biker (Priest) on Apr 24, 2002 at 08:12 UTC
|
I have a set of Perl programs that run in a controlled infinite loop. They are all supposed to work n times per minute and sleep inbetween. Furthermore, they are supposed to work at given moments in the minute, like for instance every time the seconds show 15 or 45.
As a way to control when these programs should execute or not, I use the CPAN module
Schedule::ByClock, which will let me configure at what seconds in the minute the program should wake up and do things.
The Schedule::ByClock is a wrapper around sleep() which hides the somewhat bizarre calculation to find out how many seconds there are until the next time the seconds on the clock are for instance 12. Tricky if the seconds right now are at 57, since 12 - 57 != 15 and 15 is indeed the number of seconds to sleep() to reach the moment when the seconds are 12. (It's even tricky to explain in a clear way. ;-)
The module can also wait until given minutes within the hour, but I've never had reason to use that feature.
Everything went worng, just as foreseen.
| [reply]
[d/l]
[select] |
|
|
$ perl -le '$now=57; $then=12; print +($then-$now)%60'
15
-Blake
| [reply]
[d/l] |
|
|
my $th=Schedule::ByClock->new(12,33,55); # Some already defined values
while(1) {
$th->get_control_on_second();
work_hard();
if(condition()) {
$th->get_control_on_second(42); # Special case.
additional_work();
}
}
which gives a very clean main logic. I'm sure that it can be built in many ways (TMTOWTDI) but I really like this module. It's hiding the implementation details in a clean way.
Everything went worng, just as foreseen.
| [reply]
[d/l] |
Re: infinite loops == bad?
by traveler (Parson) on Apr 23, 2002 at 22:01 UTC
|
Keep in mind that many (most? all?) GUIs and other event-driven programs are based on infinite loops of a sort. They tend to have something like:
running = true;
process_events while running;
To end the loop process_events or a function it calls sets running to false (perhaps by an object method).
Of course, the loop is not technically infinite, but in reality it often is. Some GUI main loops. for example, are "never" expected to return.
In college I was taught to write loops this way even if I never set running to false. I did not see the point. Unless you can actually end the loop use a true infinite loop.
HTH --traveler
| [reply]
[d/l] |
Re: infinite loops == bad?
by dthacker (Deacon) on Apr 23, 2002 at 22:04 UTC
|
<soapbox>
As a sysadmin, I have to be overwhelmingly convinced that you know what you're doing before you put an app that runs in an infinite loop on one of my servers. I'll also ask you to give me a way to gracefully terminate your app, and a way to monitor it to see if it's really doing what it's supposed to. If you're running things at home on your development box, that's one thing. If you're becoming part of my production environment, your app better mind it's manners.
</soapbox>
Dave
Code On!
| [reply] |
Re: infinite loops == bad?
by thunders (Priest) on Apr 24, 2002 at 13:35 UTC
|
Any Perl-Tk program is an infinite loop, other here have mentioned other programs that have similar properties. But I draw a line between programs that are infinite on purpose and those that are simply broken.
Best way to tell the difference? If you need to hit Control-C or use kill, pskill Xkill or Task Manager, or a similar utility to stop your program, that may be a "bad" infinite loop. Take perl Tk for example, Your "infinite" loop is listening for events, and this allows you to code a proper exit or even a shutdown sequence. That way you can close your filehandles database handles etc. Your program could listen for events or other input to figure out when to exit.
| [reply]
[d/l] |