Hello gRPC Team, I have taken an extract from *“include/grpcpp/impl/codegen/async_stream.h”*
*“* /// Request the writing of \a msg with identifying tag \a tag. /// /// Only one write may be outstanding at any given time. This means that /// after calling Write, one must wait to receive \a tag from the completion /// queue BEFORE calling Write again. /// This is thread-safe with respect to \a AsyncReaderInterface::Read /// /// gRPC doesn't take ownership or a reference to \a msg, so it is safe to /// to deallocate once Write returns. /// /// \param[in] msg The message to be written. /// \param[in] tag The tag identifying the operation. virtual void Write(const W& msg, void* tag) = 0; “ After reading the highlighted part, I can make the following two inferences: 1. Only one write is permissible per stream. So we cannot write another tag on a stream until we receive a response tag from the completion queue for the previous write. 2. Only one write is permissible on the completion queue with no dependency on available streams. When multiple clients connect to the grpc server, then we will have multiple streams present. Now in such a scenario, only one client can be responded to at a time due to the above-highlighted limitation. Can you please help us in understanding which one of our above inferences is true? Recently, I came across an issue where the gRPC client became a zombie process as its parent Python application was aborted. In this condition, the previous Write done on the stream connected with the client did not get ack, probably, and I did not receive the Write tag back in the completion queue for that Write. My program kept waiting for the write tag and other messages continued to queue up as the previous Write did not finish its life cycle and hence I could not free the resources also for that tag. I was wondering if I could have gone ahead with Write for other streams and queue up messages related to this stream till we get a write tag in return for the previous message. If I kill the zombie and clean up on the client, the Write tag is returned Alternatively, is it possible to force cleanup the inactive gRPC session ? What would happen if the Write tag is returned after the internal memory for that tag had been cleaned up . I guess it will crash. Please clarify the doubts, Regards Ashutosh (Ciena) -- 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/686fc0c2-6191-4a69-82dc-82f2299a908dn%40googlegroups.com.
