Skip to content

ChannelIterator: add an example #4539

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
murfel wants to merge 4 commits into
base: master
Choose a base branch
from
+42 −1
Open

ChannelIterator: add an example #4539

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
88a2ec3
add an example, stress that different coroutines *can* iterate over t…
murfel Oct 9, 2025
4ac5121
add "created"
murfel Oct 9, 2025
9d2c273
fix
murfel Nov 7, 2025
742262d
add wording on hasNext/next
murfel Nov 7, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 42 additions & 1 deletion kotlinx-coroutines-core/common/src/channels/Channel.kt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1050,7 +1050,48 @@ public inline fun <T> ChannelResult<T>.onClosed(action: (exception: Throwable?)

/**
* Iterator for a [ReceiveChannel].
* Instances of this interface are *not thread-safe* and shall not be used from concurrent coroutines.
* Instances of this interface are *not thread-safe*.
* A coroutine is only allowed to call methods on those iterator instances which it instantiated.
Copy link
Collaborator

@dkhalanskyjb dkhalanskyjb Dec 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still not true. The only limitation is that it's non-thread-safe, but like with most other non-thread-safe structures, you can still use it from different threads:

import kotlinx.coroutines.channels.*
import kotlinx.coroutines.*
import kotlinx.coroutines.sync.*

suspend fun main() {
    val channel = Channel<Int>()
    val iterator: ChannelIterator<Int> = channel.iterator()
    val mutex = Mutex(locked = false)
    withContext(Dispatchers.Default) {
        repeat(10) { coroutine ->
            launch {
                repeat(10) { iteration ->
                    mutex.withLock {
                        repeat(10) {
                            iterator.hasNext()
                            println("Coroutine $coroutine, iteration $iteration: ${iterator.next()}")
                        }
                    }
                }
            }
        }
        launch {
            repeat(1000) {
                channel.send(it)
            }
        }
    }
    println("Done")
}

No one's stopping us from protecting an iterator with an asynchronous mutex, or a synchronous one, or even sending an iterator from one coroutine to another via other channels once every dozen operations, and then operating on it with complete confidence.

This distinction is not me being pedantic. There are often cases when it actually matters which specific thread (or much more rarely, coroutine) runs some code. We could have added some logic to the ChannelIterator initializer that would check if it's still running on the same coroutine, throwing an exception if it isn't. Some APIs do operate like that. We haven't and aren't planning to. I can't imagine use cases where it makes sense to send some channel iterator to another coroutine, but it's not prohibited in the contract, nor checked in the code.

Even the original formulation is too strict, as it's possible to have safe single-threaded concurrency (on Dispatchers.Main, for example). The only problem is with parallelism.

*
* Typically, an iterator is used indirectly in the `for` loop and is not instantiated explicitly.
*
* ```
* for (element in channel) {
* // process the element
* }
* ```
*
* If your use-case requires handling the iterator directly,
* you must call [hasNext] before each [next].
* Refer to [hasNext] and [next] for more details.
*
* An example usage:
Copy link
Collaborator

@dkhalanskyjb dkhalanskyjb Oct 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you describe the sequence of events where this sample would answer a question a user may realistically have? It neither explains the next()/hasNext() interplay useful in deeply technical cases where you'd manipulate ChannelIterator manually, nor does it spell out "hey, this is not the class that you need to use manually, just write for (... in ...) instead" if that was the intention.

Copy link
Contributor Author

@murfel murfel Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm addressing my own confusion with the original wording - it primed me to think that only one coroutine is allowed to create instances of the iterator.

Copy link
Contributor Author

@murfel murfel Nov 7, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added wording on "don't use directly" and "next/hasNext"

*
* ```
* val channel = Channel<Int>()
* launch {
* channel.send(1)
* channel.send(2)
* channel.send(3)
* channel.close() // NB: must close for iterators to finish
* }
* launch {
* for (element in channel) {
* println("Consumer A got $element")
* }
* }
* launch {
* for (element in channel) {
* println("Consumer B got $element")
* }
* }
* ```
* Possible output:
* ```text
* Consumer A got 1
* Consumer A got 2
* Consumer B got 3
* ```
*/
public interface ChannelIterator<out E> {
/**
Expand Down