Assuming the server has only one service. And we want to process
multi-client requests in parallel in a multi-core system.
On Friday, October 18, 2019 at 12:22:05 PM UTC+5:30, Debashish Deka wrote:
>
> 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/ee76a1e1-cdde-46d8-8514-c753cb6ae420%40googlegroups.com.
