Integrate ticker channels into structured concurrency and flows

[elizarov]

We need to integrate ticker channels into a structured concurrency story to make sure they are not lost running forever. They should be somehow marked as "daemon" (?) children of their parent and should not prevent the parent completion, but shall be cancelled when all other (non-daemon?) children coroutines complete. This would make standard timing-related operations easy to write in a less error-prone way.

P.S. This is not critical for 1.0 release, since the API for channels is going to be kept experimental anyway.

[wyaeld]

@elizarov is this coming? Currently trying to build coroutine-based background processing but having a time-keeping channel will simplify a number of things.

[elizarov]

@wyaeld Yes. Ticker channels will become a part of Flow framework. Yet, this is not going to happen in the short-term future. Actually, flows makes it so easy to write this kind of things yourself, as to almost remove the need for any kind of library primitive.

Can you, please, write more details on what kind of background processing you are doing and what are your use-cases for time-keeping channels.

[wyaeld]

Sure. I'm reading through all the Flow docs this week to understand how that works, since that was my assumption on how you would do it. In my case I'm writing at IoT control element, which is continually processing commands that get delivered in batches, and for which I want an observer/reporting type element that is able to report say every 10s, on the status of everything in flight. This command batches can be hundreds of individual messages that have to go out. The TickerChannel seemed like a useful trigger for the reporting element.

On Tue, 3 Sep 2019 at 23:16, Roman Elizarov notifications@github.com wrote:

@wyaeld https://github.com/wyaeld Yes. Ticker channels will become a part of Flow framework. Yet, this is not going to happen in the short-term future. Actually, flows makes it so easy to write this kind of things yourself, as to almost remove the need for any kind of library primitive.

Can you, please, write more details on what kind of background processing you are doing and what are your use-cases for time-keeping channels.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Kotlin/kotlinx.coroutines/issues/540?email_source=notifications&email_token=AABGNUETUV3I64VUOU3NUFLQHZBP3A5CNFSM4FUBJY2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5X3NOI#issuecomment-527414969, or mute the thread https://github.com/notifications/unsubscribe-auth/AABGNUANWPIBKEPFFMDVIIDQHZBP3ANCNFSM4FUBJY2A .

[elizarov]

@wyaeld For your use-case we plan something like a specialized time-based chunked primitive. See #1302

[esdudnik]

Will ticker channels be multiplatform? I came from this issue https://github.com/Kotlin/kotlinx.coroutines/issues/1186 Looking for something similar for multiplatform library.

[elizarov]

Yes. The plan is to have them flow-based an multiplatform.

[MarcelReiter]

Are there any updates?

We'd like to use this feature in an app displaying a one-time-password for two-step-verification similar to the google authenticator

Usually, OTPs are valid 30 seconds, and "start" on a full minute or on a half minute, e.g. 12:00:00 or 12:00:30, but not 12:00:01

In the moment we're using rx-java and emit:

• on creation
• after (first delay), which is the time until the next 30s-interval; e.g. when it's 12:00:03 then the first delay is 27s
• each 30s after that

[YoshiRulz]

If you want another use-case: I'm writing a daemon which periodically checks the audio graph of an (external) PipeWire daemon, and creates or deletes links based on a user-defined ruleset. At the moment I'm struggling to get any timer to work, including the deprecated ticker edit: got it (though I don't understand it, and this is constant-delay not constant-interval). Here's my code:

public fun main(): Unit = runBlocking {
    JVMSoundController().use { soundController ->
        embeddedServer(Netty, port = wsProtocolPort) {
            // ... (the other half of my app, a WebSocket server for remote control)
        }.start()
        flow {
            while (true) {
                emit(Unit)
                delay(3.seconds)
            }
        }.collect {
            soundController.checkLocks()
        }
    }
}

[hugo891]

We need to integrate ticker channels into a structured concurrency story to make sure they are not lost running forever. They should be somehow marked as "daemon" (?) children of their parent and should not prevent the parent completion, but shall be cancelled when all other (non-daemon?) children coroutines complete. This would make standard timing-related operations easy to write in a less error-prone way.

P.S. This is not critical for 1.0 release, since the API for channels is going to be kept experimental anyway.

https://github.com/Kotlin/kotlinx.coroutines/issues/540#issue-358386966