Is it safe to modify the const request passed by grpc framework?

[amandee...@gmail.com]

gRPC exposes const request. However, if the RPC is carrying data (like a large string), this can be really inefficient as we will have to copy the whole string in the request if we want to do some processing.

Is it safe to review the constantness and use release_* function to take the ownership of the large string? 

[amandee...@gmail.com]

This is for C++ language.

[Eugene Ostroukhov]

It is not advisable to do that. gRPC is very careful with the memory so the memory location in that const request may be pointing to some internal buffer and might be overridden or freed when the code does not expect that.

[amandee...@gmail.com]

Hi Eugene Ostroukhov!
Thanks for the response. Is there an example of this: "const request may be pointing to some internal buffer and might be overridden or freed when the code does not expect that"?

> gRPC is very careful with the memory so the memory location in that const request may be pointing to some internal buffer and might be overridden or freed when the code does not expect that

The framework shares a shared_ptr to the request and since it is shared ownership can the grpc framework do intrusive operations?

I am more worried about the fact that if we take ownership, can it cause some corruption later on when the use_count of the pointer becomes 1 and the framework is the only one holding reference to the shared_ptr of request. This will happen once the application later has processed the request 

This is important for us because this const leads to memory copy as we transfer data using unary RPCs.

[Eugene Ostroukhov]

I can not provide a quick example for that but I do know for a fact that internally gRPC is trying to avoid memory copies so some of those string views are pointing to internal data structures. I believe I've at least seen it with initial metadata. Please do not cast the constness away.