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:
>
> 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
>
>
>
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/2402b12d-741b-497e-aa68-a3908f7323be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
