|
|
|
|
@ -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) { |
|
|
|
|
|
Vijay Pai
8 years ago