Codec with GRPC Server Support

[planetscale]

Codec with GRPC Server Support

[vmg]

let the codec release them once the wire-work has finished and the bytes are sent?

This is not safe to do at all because the wire-work in GRPC happens asynchronously in a background goroutine, so we never know when it's actually safe to return them to the pool. That's the reason why it hasn't been implemented for GRPC while we do have this feature for other systems like DRPC.

You can find on the internet several approaches to accomplish this (e.g. http://www.golangdevops.com/2019/12/31/autopool/) but none of them seem particularly reliable. An efficient implementation of memory pooling in GRPC would require upstream changes.

[jzelinskie]

If there's no safe way to return a request to the pool, there's not much of a point to pooling unless you're allocating and returning messages elsewhere in your program?

[steve-gray]

I suspect there's a few things that could be done in this scenario. It strikes me that if the _grpc.pb.go generator was likewise customised, it could be made to:

• Create the objects for requests/response from the VT Proto pooling
• Use a runtime finalizer to release them.
• When an object is returned over the wire from the invoke that object itself, if it implements the VT Pooling interfaces could be then runtime finalized too (so as long as the person generating the response object, pulled it from the pool).

This would be safe, right? Kind of feeling @jzelinskie's vibe that the pooling isn't much use without this. We're using it for some places that use protobuf for internal data representations, but it feels like a lot of the value is being left on the cutting room floor a bit.