Thank you for the explanation.
I understood the logic of one thread waiting on the queue and submitting
the tasks onto some container and the other thread processes those tasks
one by one.
I want a design where one thread should wait on the queue and push incoming
requests to a thread pool. I have already written the code for the thread
pool. Clients can request various types of request (say for example type
A,B,C). For each type of request, the server has one handler function. For
simplicity lets assume, these handlers are nothing but CPU intensive for
loops.
for example,
void handlerA() {
for_loop(1000000);
respond to client some dummy response.
}
I tried to understand the application logic of your server code. But it
contains too many handlers and confused me. Can you help me with the
above-mentioned design?
Thanks !
On Friday, March 3, 2017 at 1:04:04 AM UTC+5:30, Arpit Baldeva wrote:
>
> Hi,
>
>
>
> Recently, I have been looking into the sync and async api of gRPC (C++)
> and how to choose between them for my usage. While gRPC has excellent
> documentation and examples overall, I found this area a bit lacking. So I
> had to go through a lot of past forum posts (and post some myself) for
> gaining insights on the subject. I am attaching a doc here that details the
> difference between the two model. People might find useful when trying to
> make their decision.
>
>
>
> In addition, I implemented a set of classes that makes working with async
> API on server a bit easier from application code point of view. The
> example/test code I found would often ignore the error handling or do
> streaming calls in a way that hardly resembles how you might do things in
> your application. I realize the importance of existing example code as it
> is simple to start with however I feel a more complex example is also
> warranted. Using those utility classes, I went ahead and implemented the
> routeguide server example in a fully async fashion. So I am attaching that
> code as well in the hope that it is something other people can benefit
> from. May be it could become part of example code in gRPC codebase?
>
>
> The code is commented as much as I deemed necessary. I have also stress
> tested it with multiple threads from the client and abrupt client process
> exit. I am also attaching the client stress test code but that bit isn’t
> substantially different from the existing example code around client (apart
> from adding some threading stuff).
>
>
>
> Thanks.
>
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/dac9c394-7718-4d22-b294-42f9bb6e22d9%40googlegroups.com.
