The point is that while(1){} isn't idle, it's
spinning madly behind the scenes, testing 1 as often as possible.
In your case you probably have lots of other processes
that push your script down to .05%, but I'm just guessing on
that. On this old workstation the while(1){} goes
up above 90% when not much is happening. Now I'm certainly no expert on
process scheduling, but then neither is Win32 ;-).
I've been taught (though it may be deprecated like lots of
other things I've learned) that it's just bad manners for a
program to basically waste time spinning madly, as you don't
know what other apps might want to do with those cycles.
If you sleep() you're letting the system decide what to
do with those cycles you'd otherwise be wasting. Of course
as others have already said, it depends on just how urgent
your task is - do you need to act the same millisecond the
file is deleted, or is 1/10 of a second fast enough (and don't
forget your network latency is probably killing way more response
time than the sleep() will).
Maybe if you explain your application a bit more fully the
answer will become clearer.
--
I'd like to be able to assign to an luser | [reply]
[d/l]
[select] |
If you're using Win32, there's always Win32::ChangeNotify. This will let you wait until your specified file is changed, then take action. I use it in a script on my NT box, and it doesn't take much CPU (especially compared to while(1)!).
Guildenstern
Negaterd character class uber alles! | [reply] |