Can you help me with this issue ?
https://stackoverflow.com/questions/58499145/grpc-c-async-completion-queue-events
On Friday, October 18, 2019 at 12:28:09 PM UTC+5:30, Debashish Deka wrote:
>
> 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/e6854f9c-015e-4464-9304-69576738abdf%40googlegroups.com.
