https://kotlinlang.org logo
#coroutines
Title
# coroutines
b

brett.wooldridge

06/11/2019, 6:16 AM
…is the limitation on delay() related to the granularity of the underlying worker pool dispatcher implementation?
l

louiscad

06/11/2019, 6:18 AM
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.
b

brett.wooldridge

06/11/2019, 6:20 AM
The relationship between
suspendCancellableCoroutine
and the ability to suspend for nanoseconds (or microseconds) is not clear to me.
l

louiscad

06/11/2019, 6:21 AM
You can write your own
delayNanos
function with it and an API from the platform that allows delaying with nanoseconds parameter.
(single backticks will work for you, try editing your message)
b

brett.wooldridge

06/11/2019, 6:24 AM
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).
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?
o

octylFractal

06/11/2019, 6:33 AM
remember that Kotlin is not a JVM-only language -- it also supports JavaScript, which does not offer nanosecond accuracy in most browsers, iirc.
b

brett.wooldridge

06/11/2019, 6:36 AM
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.
(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)
e

elizarov

06/11/2019, 6:52 AM
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.
o

octylFractal

06/11/2019, 7:02 AM
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.
b

brett.wooldridge

06/11/2019, 7:11 AM
yeah, i’ve watched the videos on the underlying implementation of the resume dispatching.
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?
12 Views