What is a good way to schedule a repeating task in a platform agnostic way?

fun main() = runBlocking {
    val component = Component {
        var a = 0; var b = 0
        every(50.milliseconds) {
            if (it % 20 == 0) println("A: ${a++}")
        }
        every(1.seconds) {
            println("B: ${b++}")
        }
    }
    component.enable()
    delay(50.seconds)
    println("Done!")
}
context(Toggled) @Base
suspend fun every(period: Duration, block: suspend (Int) -> (Unit)) {
    simultaneously {
        var i = 0
        while (isActive) {
            block(i++)
            delay(period)
        }
    }
}

The problem with this is that over time the two tasks get way out of sync: A: 47 B: 49 After 50 seconds

This is normal, other things are running, clocks are not reliable, ... scheduling things is always best effort.

I would recommend looking at Arrow Fx’s

Schedule

https://arrow-kt.io/docs/apidocs/arrow-fx-coroutines/arrow.fx.coroutines/-schedule/

I agree scheduling is normally best effort, but like ScheduledExecutor will correct itself rather than getting further and further off schedule IIRC. I'll checkout Arrow's solution that looks great thank you very much!

You can get an initial time stamp and then delay for

startTime + i * period - now()

This approach will still drift over time but it might not matter if your period is long enough and your task is relatively short. If you need more precision, a

fixedRateTimer

(or

NSTimer

on iOS) is the only way to get tight non-drifty periodicity.

Why would it drift, assuming you have a decent clock? My theorie goes each error is corrected in the next interval so errors do not accumulate.

I suggest closely testing your interval loop. I was trying the same approach for a fairly precise 500ms ticker on mobile and it would drift by seconds over the course of 10 minutes. The milliseconds add up if your interval is short enough.

What does the fixedRateTimer do that the nextTick concept does not?

It’s implemented with

java.util.Timer

underneath which doesn’t have a real-time guarantee but in my testing it offers more consistent timing than using

delay

. Also

fixedRateTimer

has the added bonus of being part of the jvm stdlib.

The timing qualities of

delay

probably depend on the thread you schedule on. If you delay on a busy dispatcher you are off. But non of that should cause a drift (i.e. accumulate errors).

Right now I'm seeing pretty good consistency using nextTick, no drift. Obviously, on a busy or single-threaded dispatcher, the average time between calls isn't perfect but that's ok for me.

I have done the same thing, and measured the drift and jitter between a delay() based simple scheduler (same concept, each delay use the (next interval - current time) -- I measured best using delay over Thread.sleep() or java.util.Timer over long periods. If drift is accumulating -- it must be due to some bug -- One factor - think through the case where the work takes longer then a cycle, that can accumulate drift BIG TIME if you dont accommodate it or have a bug in it due to getting delay going negative. When I accounted for the following -- I got a very stable cycle +/- 1ms usually (when measured with NS timer) val CYCLE=1000 var start = now() var tick = 0 while(true){ doWork() val sleepUntil = start + tick++ * CYCLE delay( sleepUntil - now ) } if doWork() takes longer then 1000ms ever then you get out of step and delay for a negative value (or zero if you ensureAtLeast) once that happens then you can start drifting if using something like above -- unless you decide what to do> In my case I would do the equivilent of bumping up tick until it reached the present This has the effect of skipping a cycle . In cases like this you have to tollerate either conserving the number of ticks or conserving the periodicity, you cant do both