On the CoroutineScope interface a would put something like the following to show how it may be used class LifecycleAwareClass : CoroutineScope { private val job = Job() override val coroutineContext: CoroutineContext get() = job + TODO() //... } On the shared state. The synchronized is not the kotlin way right? Is it mentioned as an equivalent with Mutex? Regarding Actors I would used a sealed class as a base for the messages (like in the official doc https://kotlinlang.org/docs/reference/coroutines/shared-mutable-state-and-concurrency.html#actors)

I should probably add some ways to make a scope 🤔 Too little space to use it though. I really want to fit it all in a single page. BDW this is why I removed sealed class in the actor example - not necessary and takes extra space (especially

actor

typing makes this line too long to fit)

I thought that Mutex is the way to go for Kotlin in use cases that you would use syncronized https://kotlinlang.org/docs/reference/coroutines/shared-mutable-state-and-concurrency.html#mutual-exclusion

I did not have many cases to use this in the real world yet. But I thought that is what the doc is suggesting

@marcinmoskala You could add a password to the WIP pdf file so it doesn't get in the wild so easily

Here is the file after corrections. Though selection is still not possible because we are sending it to another person to generate selectable version (Adobe Illustrator is needed for that)

val producer = produce {
            for(i in 1 .. 5){ send(i * i) }
        }

        println(producer.receive()) //1
        println(producer.receive()) //4

        for(element in producer){
            println(element) //9, 16, 25
        }

? Also consider that

consumeEach

has scary warnings on it about being changed in future is tagged with

ObsoleteCoroutinesApi

also

Dispatchers.Unconfined

does not change thread implies something semantic when I really think its only safe to use this for performance/debugging. Maybe say "Use first available dispatcher for performance"?

For example in the builders section I can't understand right now if

withContext

is blocking