If you don't mind multiple parallel loops, you can implement a "scheduler". It works by using something like a Queued Message Handler to execute "Commands" at specified times. One loop is the "clock" -- use Timed Loop or a While Loop with a Wait until Next Multiple. Each "tick",fire a Notifier with the current time (in my case, I use a millisecond counter, so I put a millesecond count in the notifier).. We'll get to what to do with the Notifier in a minute. The Scheduler is an Action Engine, with four actions -- Initialize (save the current time, or milliseconds), "Save Action" which saves the time (in the future) you want a Command to be executed, and the name of the Command (for example, "Write to Disk" = command, "1000 msec" = when to do this, "Do Action" which looks at all the saved Actions and, if it is time to do any of them, calls the Queued Message Handler to do them (e.g. put the message "Write to Disk" on the QMH Queue). If it does call the Message Handler, it removes the Command from the Schedule. Finally, there is a Quit, which flushes the Schedule and exit. Note that I also clear the Schedule when I Initialize the Scheduler -- this lets me set several "Time Zeros". Now for the Notifier -- have a loop that simply "fires" the "Do Action" action of the Scheduler. So why use a Notifier? it basically allo you to "miss" a clock tick. Finally,there's the QMH do the Commands.
It sounds a little complicated, but it works quite well. The amount of overhead it pretty trivial -- if you run on a millisecond clock, I'd estimate that the overhead is no more than a few microseconds, much less than 1%. So you can schedule what you want to do when y ou want to do it.