aboutsummaryrefslogtreecommitdiffhomepage
path: root/doc/combiner-explainer.md
diff options
context:
space:
mode:
Diffstat (limited to 'doc/combiner-explainer.md')
-rw-r--r--doc/combiner-explainer.md8
1 files changed, 4 insertions, 4 deletions
diff --git a/doc/combiner-explainer.md b/doc/combiner-explainer.md
index 9d0a4f30f2..9e9d077273 100644
--- a/doc/combiner-explainer.md
+++ b/doc/combiner-explainer.md
@@ -92,7 +92,7 @@ class combiner {
So that explains how combiners work in general. In gRPC, there is
`start_batch(..., tag)` and then work only gets activated by somebody
-calling `cq::next` which returns a tag. This gives and API-level
+calling `cq::next` which returns a tag. This gives an API-level
guarantee that there will be a thread doing polling to actually make
work happen. However, some operations are not covered by a poller
thread, such as cancellation that doesn't have a completion. Other
@@ -128,12 +128,12 @@ tries to spray events onto as many threads as possible to get as much concurrenc
So `offload` really does:
```
- distributor.run(continue_from_while_loop);
+ workqueue.run(continue_from_while_loop);
break;
```
-This needs us to add another class variable for a `distributor`
-(called a `workqueue` in the code).
+This needs us to add another class variable for a `workqueue`
+(which is really conceptually a distributor).
```
workqueue::run(f) {