@@ -1097,7 +1097,13 @@ fun filter(context: CoroutineContext, numbers: ReceiveChannel<Int>, prime: Int)
1097
1097
```
1098
1098
1099
1099
Now 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,
1101
1107
running the whole pipeline in the context of the main thread:
1102
1108
1103
1109
``` kotlin
@@ -1128,6 +1134,17 @@ The output of this code is:
1128
1134
29
1129
1135
```
1130
1136
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
+
1131
1148
### Fan-out
1132
1149
1133
1150
Multiple coroutines may receive from the same channel, distributing work between themselves.
0 commit comments