Open arthur-tacca opened 5 years ago
gRPC follows the style guide that it does not maintain a reference or a pointer to anything that's passed in with a const reference so reply_ can be safely destroyed immediately after it. You are right in thinking that internally we serialize it immediately
In the implementation of an async C++ server, you will end up calling
ServerAsyncResponseWriter<T>::Finish()
in order to send a reply to the client. Here is the relevant line from thegreeter_async_server
:As context / a reminder: It is certainly necessary to ensure the lifetime of the
ServerAsyncResponseWriter<T>
object (i.e.responder_
) extends until the tag is posted again to the completion queue. In that example the tag isthis
, and when it is posted to the completion queue it is deleted (becausestatus_ == FINISH
); the objectresponder_
is a data member, so that gets destroyed to.My question is: Is it necessary to ensure the lifetime of the response object (i.e.
reply_
in this example) also extends until the tag is posted again to the completion queue, or is it acceptable for it to be destroyed immediately after the call toFinish()
? In other words, doesFinish()
immediately serialise the response to a buffer, or does it retain a pointer to the response. In the greeter example,reply_
is a data member ofCallData
so is destroyed at the same time asresponder_
, but it is not clear if that is necessary or an implementation detail. Ideally, the response to this question could be recorded in the async greeter documentation.I realise I could just play it safe and keep the response object lying around, but there are a few undocumented things in the C++ async APIs, especially around object lifetimes and whatnot, so one less thing to guess at would be nice.