Programming

What poor implementation? Did I make a mistake in the code? Does it not work?

Using a high speed polling loop with a 10 micro second delay (apparently to avoid a race condition) to schedule tasks that occur in seconds.

That means for every second, you will wake up and execute the loop 100,000 times before you will ever find anything to do. If you have to delay 10 seconds as was originally requested, your loop would have spun a million times before it had to do anything useful.

Simply using a variable for the usleep() parameter that was the number of microseconds between now and the next timed event would have been an excellent solution.

True, but then the function can only act as a cron manager. The object is meant to be used from within a game loop. That seems far more useful than a discrete utility designed only to sleep for specified number of milli seconds. Besides, the simple sleep method may not take into account how long it takes to execute the function before triggering again.

Anyway, it's just one of many ways to accomplish the task at hand. I didn't mean to strike a nerve.

I spent 3 months on something like this a few years ago. QA beat up on it pretty hard, it seemed to hold up well.

It may be fine code for a single user/single threaded/single application Playstation but not on a multiuser multiprocessing platform.

Also it's bad practice on a battery powered device as the goal is to do nothing as efficiently as possible, ie let the device go to sleep for the longest period.

interesting - I didn't even realize this was for use in a battery powered device. I guess there are a billion things it could be used for, and there are probably billion different ways to do it.

So, what is really the best (hopefully somewhat platform independent) way to accomplish this? Is there one? A project that I worked on a few years ago would have been best done if I had known how to really take advantage of a Sun kernel, but I didn't, and neither did anyone else at the shop, so we just used the clock. It held up well enough, but, we did consider exploring options using traps and signals.

WebKruncher, porter could be more diplomatic, but he does have a point. You are proposing something like:

Code:

trigger=time(NULL)+90;
while (1) {
         if (time(NULL)>trigger) {
                    trigger=time(NULL)+90;
                     do_something();
                     }
         usleep(10);
}

That is not a great way to arrange for something to happen every 90 seconds on any platform. If a process has nothing to do for 90 seconds, then it should do nothing during that 90 seconds. This is true on every platform. The problem is that you are busy looping waiting for 90 seconds to pass. If you replace "usleep(10)" with some code that does useful important work, then you basicly have a technique I would use to display a progress message as a very lengthy program runs. I don't care if the message is several seconds late. But the trigger test is in a main loop that is doing something useful. Take out the time test and my program remains useful. But take out your trigger test and you are left with:
while(1) usleep(10);
That puts quite a load on a system for no good reason.

If there is nothing to do in the loop but wait for 90 seconds to pass, I would simply use:

Code:

while (1) {
        do_something();
        sleep(90);
}

On every system I know, this is a much better solution than spinning in a loop waiting for 90 seconds to pass.

Why do want that loop running during the 90 second delay? Do you realize that the system is doing a lot of work that has no effect? If you are determined that you absolutely must have a loop spinning during the 90 second delay, you could improve the situation quite a bit by simply increasing usleep constant, say to 500000. Or replace it with sleep(1) or even sleep(10). You are still forcing the OS to run your process periodically. But at least not as often.