@@ -1097,7 +1097,13 @@ fun filter(context: CoroutineContext, numbers: ReceiveChannel<Int>, prime: Int)
10971097```
10981098
10991099Now we build our pipeline by starting a stream of numbers from 2, taking a prime number from the current channel,
1100- and launching new pipeline stage for each prime number found. The following example prints the first ten prime numbers,
1100+ and launching new pipeline stage for each prime number found:
1101+
1102+ ```
1103+ numbers -> filter(2) -> filter(3) -> filter(5) -> filter(7) ...
1104+ ```
1105+
1106+ The following example prints the first ten prime numbers,
11011107running the whole pipeline in the context of the main thread:
11021108
11031109``` kotlin
@@ -1128,6 +1134,17 @@ The output of this code is:
1128113429
11291135```
11301136
1137+ Note, that you can build the same pipeline using ` buildIterator ` from the standard library.
1138+ Replace ` buildSequence ` with ` buildIterator ` , ` send ` with ` yield ` , ` receive ` with ` next ` ,
1139+ ` ReceiveChannel ` with ` Iterator ` , and get rid of the context. You will not need ` runBlocking ` either.
1140+ However, the benefit of a pipeline that uses channels as shown above is that it can actually use
1141+ multiple CPU cores if you run it in [ CommonPool] context.
1142+
1143+ Anyway, this is an extremely impractical way to find prime numbers. In practise, pipelines do involve some
1144+ other suspending invocations (like asynchronous calls to remote services) and these pipelines cannot be
1145+ built using ` buildSeqeunce ` /` buildIterator ` , because they do not allow arbitrary suspension, unlike
1146+ ` buildChannel ` which is fully asynchronous.
1147+
11311148### Fan-out
11321149
11331150Multiple coroutines may receive from the same channel, distributing work between themselves.
0 commit comments