Okay thanks for explanation @elizarov , I think Im getting a bit ahead of myself though in hindsight. Still need to work through the co-routines documentation on github. @kirillrakhman thanks, code noted, will try once Im a bit further along

Channels indeed provide a direct replacement for blocking queues when you work with coroutines

moved from #getting-started Any best practice to implement job queue in Kotlin using coroutines? Here is my code

val queue = LinkedBlockingQueue<Note>()
    var closed = false

    init {
        async(CommonPool) {
            while (!closed) {
                while (!closed && queue.isEmpty()) {
                    delay(50)
                }
                while (!closed && !queue.isEmpty()) {
                    play(queue.take())
                }
            }
        }
    }

I don't like

delay(50)

and I think it's not sufficient. 3 replies Channels indeed provide a direct replacement for blocking queues when you work with coroutines

@kirillrakhman That is not weird. All async coroutines are composable. It is generally ok to use child-coroutines and suspend an asynchronous coroutine using any asynchronous suspending function.

@s1m0nw1 Just a suggestion make the (1) comments as I got very confused reading it at first glance

@jkbbwr thx for reminding me... I had planned to fix that, bothered me too

👍

Updated

@vaskir has left the channel

@s1m0nw1 What is the point of calling

launch(CommonPool) {}.join()

inside

runBlocking(CommonPool) {}

in this example:

runBlocking(CommonPool) { //(1)
    launch(CommonPool) {
        sendEmailSuspending() //(2)
        LOG.debug("Email sent successfully.")
    }.join() //(9)
}

@ilya.gorbunov The

main

would terminate before all outputs can be observed. I get what you mean though and updated it to:

runBlocking(CommonPool) { //(1)
    val job = launch(CommonPool) {
        sendEmailSuspending() //(2)
        println("Email sent successfully.")
    }
    job.join() //(9)
    println("Finished")
}

Now we want to do something after the email was sent which makes join reasonable. All right?

https://blog.simon-wirtz.de/kotlin-coroutines-guide/ is println("The result: ") is gauranteed to print before println("$result") ? @s1m0nw1

Well I would not give you my word on this! But normally it should 😉

@karelpeeters has left the channel

@elizarov thanks! 🙂

@rogeralsing Answering your question in the above thread. There is no much need to have anything like .NET’s

Task.FromResult(...)

, because there is no much need to define functions that return

Deferred<T>

(like

Task<T>

in .NET). Writing

suspend

functions with natural return types is so much nicer and you just

return

from them normally and invoke them normally. However, having the corresponding constructors for

Deferred

would not harm either.

@User uploaded a file:

I've just ported my actor lib to Kotlin + coroutines 🙂

early bits: https://github.com/AsynkronIT/protoactor-kotlin

love it

I wrote a C# to Kotlin transpiler first to do it 🙂 that took care of 90% of the job... https://github.com/rogeralsing/ProjectExodus if anyone ever finds a need to port .NET stuff

@rogeralsing Did you like the experience? What was good/bad? Anything we can improve?

Loved it, the code is a lot cleaner than the C# counterpart. biggest hurdle was no exposure to JVM, Kotlin or Kotlin coroutines before 😛

copied from #general as it might be more appropriate here

Guys, do you know whether theres is a way to tell kotlin compiler NOT to optimise some `var`s? Here's my example on JVM (#coroutines) :

fun <T> ReceiveChannel<T>.reduce(reducer: (T, T) -> T) = produce<T>(Unconfined) {
    var prev: T? = null
    for (elem in this@reduce) {
        if (prev == null) {
            prev = elem
            send(elem)
        } else {
            val new = reducer(prev, elem)
            prev = new
            send(new)
        }
    }
}

When run in debug mode everything works fine. However when run normally reading from

prev

always returns

null

- I suppose some "optimisation" is taking place in non-debug builds.

@rafal I don't know enough about coroutines to see what the issue is, but you probably have a race-condition in there somewhere. These types of bugs typically don't show up in the debugger, making them some of the most annoying ones to deal with.

@karelpeeters even when setting coroutine context as

newSingleThreadContext

(whole

produce

code is run inside one thread), the issue persists

@rafal There is no difference in code produce between debug and non-debug. Can you post a link to a self-contained example that reproduces a problem?

@elizarov here's repo with isolated code https://github.com/rciurkot/reduceKt