Grpc Async Server Threading Model (After reading relevant tests)

[Lei Wang]

After my careful study on "https://github.com/grpc/grpc/blob/master/test/cpp/qps/server_async.cc:" suggested in another topic "GRPC Threading Model", I have some concreted questions wandering in my mind, because

user has to provide their own threading models. Since I am implementing pubsub services on top of grpc, threads are important for stream rpc performance. I am seeking help from grpc community. 

I am implementing a aysnc grpc pubsub services (multiple services methods), and try to utilize multi threads to boost performances. Solution form "https://github.com/grpc/grpc/blob/master/test/cpp/qps/server_async.cc:" just tell me that each thread handles a unique CallData object (ServerRpcContext instance): 

one thread <-> one completion queue <-> one grpc server context, one rpc method (CallData instance with its address as a unique tag)

I am familiar with hands on experiences of Linux event handling mechanisms of epoll , kqueue, and select. Now I am curious about what are the differences of the following grpc threading models and how to implement them in pubsub server and client sides:

1 thread <-> 1 completion queue <-> mutliple rpc methods handling

1 thread <-> multple completion queue <-> multiple rpc methods handling

many threads <-> 1 completion queue

many threads <-> many completion queue

[Lei Wang]

More specifically, do I need ThreadPool to manage tasks? Or I just need run multiple threads for a completion queue with multiple rpc methods registered and join them at the end ?  

[Lei Wang]

I am trying to implement a thread_pool so that each time a CallData arrives from the completion queue, I queue a task to the thread pool so that a thread can get it from a thread safe queue.

Can anybody tell me more about these codes which appear in cpp test files:

do {
 ctx = detag(got_tag);
...
} while (some_cq_for_this_thread->DoThenAsyncNext(lambda))

The lambda doing the following things:

take in : ctx (CallData), ok (bool), mu_ptr (std::mutex*) 

The body of the lambda triggers an invoker (a specific async rpc method handler derived from some sync ServiceImpl) and re-initiates the async request method.

Something unpleasant to me:

First, in demo, we will check a state, it seems that we don't have to and the demo is misleading. I personally love using such a method pointer to exchange next_state so that we can finish initiate a method and handle it recursively.

Second, I have no idea how DoThenAsyncNext works. Why don't we use a forever loop?

Third, the double locks are tricky here

Finally, 

On Wednesday, February 20, 2019 at 2:12:29 PM UTC+8, Lei Wang wrote:

[Lei Wang]

Also see discussion https://github.com/grpc/grpc/issues/18055

On Wednesday, February 20, 2019 at 2:12:29 PM UTC+8, Lei Wang wrote: