…is the limitation on delay() related to the granularity of the underlying worker pool dispatcher im...

# coroutines

[brett.wooldridge]

…is the limitation on delay() related to the granularity of the underlying worker pool dispatcher implementation?

[louiscad]

Most OSes don't have true nanosecond precision, so milliseconds was used. It's also more natural to human mind.
You can still register a callback to execute after nanoseconds if the platform you're developing for has that capability (despite it probably not having precision guaranteeds), using suspendCancellableCoroutine like with any single execution cancellable/unregisterable callback.

[brett.wooldridge]

The relationship between suspendCancellableCoroutine and the ability to suspend for nanoseconds (or microseconds) is not clear to me.

[louiscad]

You can write your own delayNanos function with it and an API from the platform that allows delaying with nanoseconds parameter.

[louiscad]

(single backticks will work for you, try editing your message)

[brett.wooldridge]

Ok, I understand. I was just curious why Kotlin did not choose to offer such a method. Obviously, all JVM-based platforms have `parkNanos()`` available. (obviously, with actual accuracy depending on the underlying OS).

[brett.wooldridge]

One question I have is that, obviously, parkNanos() is a blocking call, but delay() is a suspending call, so how is the delay itself achieved without invoking an underlying blocking platform call?

[octylFractal]

remember that Kotlin is not a JVM-only language -- it also supports JavaScript, which does not offer nanosecond accuracy in most browsers, iirc.

[brett.wooldridge]

So that is the reason for its omission, or is that supposition? Just like `parkNanos()`` makes no guarantees on granularity, it seems a similar `delay()`` could be offered with similar “best effort” contract.

[brett.wooldridge]

(after all, all delays/sleeps have variance except in realtime OSes, so a delay(20ms) may not actually resume until tens, hundreds, or even thousands of milliseconds later)

[elizarov]

No hidden thoughts. Millis are simply the most common unit on JVM. With the upcoming Duration support in stdlib, you’ll be able to request delay with any precision to exploit the full potential of your target platform.

[octylFractal]

re: "`parkNanos()` is a blocking call, but delay() is a suspending call", it depends on the underlying implementation, but typically, the thread pool will do the blocking. the difference being, the thread pool can do other work that is ready while waiting for your task to finish delaying, since it knows of all the tasks it needs to be executing.

essentially, when you call delay(), Kotlin schedules a task after the delay that calls back into your method to continue execution. see the generated bytecode, it basically is a switch statement to which part of the method it should be executing, and suspending will just tell it to call the next part.

[brett.wooldridge]

yeah, i’ve watched the videos on the underlying implementation of the resume dispatching.

[brett.wooldridge]

It looks like the jvm implem,entation of CoroutineScheduler already uses parkNanos() and does all internal math based on nanoseconds…would be nice to have it exposed. When is Duration expected to be added to stdlib? 1.4?