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.