3

gRPC provides asynchronous C++ client API that uses CompletionQueue to fetch responses. For similar asynchronous behavior it is also possible to use synchronous gRPC API and launch each call in it's own thread, e.g. by using std::async.

Some common problems attributed to use of threads are

  • writing thread safe code is more difficult

  • starting threads has some overhead

But to me it looks like gRPC async client needs thread anyway for reading CompletionQueue (it's blocking), and overhead of starting thread is very small compared to overhead of RPC to another process or computer.

If asynchronous behavior is required, what are benefits of "real" asynchronous gRPC API compared to running synchronous calls in threads?

jviita
  • 114
  • 2
  • 11
  • Check out this link for an explanation of why you might want to use an async API over threads: https://stackoverflow.com/questions/4024056/threads-vs-async . – parktomatomi Nov 21 '19 at 20:36
  • Switching threads is costly too, because it has to swap out the virtual address table and registers - https://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html . Coroutines _can_ run in multiple threads but many can fit in the same thread without a context switch. You won't see a benefit for a few concurrent tasks, but for massively concurrent loads like web servers it makes a huge difference. – parktomatomi Nov 26 '19 at 13:51

0 Answers0