Re^4: do something no more than 3 times a second

If you want a busy loop, just comment out the sleep line. I don't see how that makes any sense, though.

Of course, it can, if you use a HiRes timer.

You have to use a timer either way. Or is hires somehow meaningful in that sentence? I don't see why, so could you give a example reason?

there *are* cases where it makes more sense

What would be such a case? I can't think of an example where doing a busy loop is acceptable if the system has a notification API. (In this case, sleep is that API since we're only interested in waiting for an amount of time.)

Comment on Re^4: do something no more than 3 times a second Select or Download Code

Replies are listed 'Best First'.
Re^5: do something no more than 3 times a second by rovf (Priest) on Nov 29, 2010 at 10:00 UTC
If you want a busy loop, just comment out the sleep line. This would not fulfil the requirement that at most three service calls must be done. For doing this, you also have to monitor the time (though you don't have to do it using a timer). Application where I would do a busy loop instead of using a sleep: I'm running on a system where Time::HiRes is not available I'm running on a system where there isn't going on much more critical stuff except my process, so I don't care eating CPU cycles by a busy loop I find that doing one service call in average takes 0.3 seconds or longer, so I don't consider it worth saving cycles by doing micro-sleeps -- Ronald Fischer <ynnor@mm.st>	[reply] [d/l]
Re^6: do something no more than 3 times a second by ikegami (Patriarch) on Nov 29, 2010 at 16:54 UTC
This would not fulfil the requirement that at most three service calls must be done. For doing this, you also have to monitor the time (though you don't have to do it using a timer). It does fulfill the requirements. It does monitor the time. I'm running on a system where Time::HiRes is not availabl For this particular example, install it or use `select`. In general, this would be the aforementioned "no API available" reason. I find that doing one service call in average takes 0.3 seconds or longer, so I don't consider it worth saving cycles by doing micro-sleeps The reason it's ok to waste CPU is that it's not worth saving CPU cycles? That's not a reason for using a busy loop; it's not even a valid argument. I'm running on a system where there isn't going on much more critical stuff except my process, so I don't care eating CPU cycles by a busy loop So the reason for using a busy loop is that you're no worst off at the best of times? I'm not sold.	[reply] [d/l]
Re^7: do something no more than 3 times a second by rovf (Priest) on Dec 01, 2010 at 08:40 UTC
> This would not fulfil the requirement that at most three service calls must be done. > For doing this, you also have to monitor the time (though you don't have to do it > using a timer). It does fulfill the requirements. It does monitor the time. Right, I should have looked more carefully. For this particular example, install it I think I should have been more precise. When talking about when a busy loop might be more appropriate than using the HiRes timer, I meant that we might be on a system where HiRes would not work. From the perldoc of HiRes: The "Time::HiRes" module implements a Perl interface to the "usleep", "nanosleep", "ualarm", "gettimeofday", and "setitimer"/"getitimer" system calls, so I think this means you need at least a platform having these system calls. Note that I'm not against using Timer::HiRes. I just wanted to point out to the OP that if he doesn't WANT to use a sleep, he could alternatively do it using a busy loop. -- Ronald Fischer <ynnor@mm.st>	[reply] [d/l]