Hi, I believe, GRPC streaming RPC will be beneficial for this use case. Where you can have one client and share that with multiple threads and make sure the client write is protected so that only one thread writes at a time. Here, in streaming RPC, it is not necessary to wait for ack/reply from the server.
On Wed, May 3, 2023 at 7:18 AM vinay Nayak <[email protected]> wrote: > Hi > In GRPC Asynchronous Streaming , it is mentioned that we cannot do back to > back write() on the same RPC Call and we can do next Write() only after > getting back tag from completion queue. > > Suppose if the application is multi threaded and if any given thread can > do Write(), to synchronize between getting tag from CQ and allowing next > Write(), we might need to use mechanism like signaling a thread which is > waiting to do next Write() Operation. > > Is application thread waiting for subsequent writes is the expected > behavior . Am i missing anything ? > > If so, it adds latency in the communication of messages between services. > Is this acceptable ? This way it can impact the performance of the > application. > > > -- > 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/3a088d23-74af-4fc7-9b02-c56e286b8fd7n%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/3a088d23-74af-4fc7-9b02-c56e286b8fd7n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Thanks, Sidhartha Thota. -- 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/CALguN-FJP9PhJgOyofEX72dM4-pVFHesk%3DanXqaSiW_NA0vMKg%40mail.gmail.com.
