I can imagine a hundred scenarios where 'delete this;' <https://github.com/grpc/grpc/blob/v1.33.1/examples/cpp/helloworld/greeter_async_server.cc#L115> at the end of the CallData state machine is never reached.
How about, if we simply start the server and shut it down without any RPC calls? proceed would never be called three times, and therefore the delete is never reached. In fact, it seems to me there is always at least one outstanding instance that will never have proceed called again on server shutdown. Additionally, if any exception were to occur during processing, it would be lost forever. Trying to sort this out while not understanding grpc and trying to make sense of it, itself, makes this example absolutely horrid. Is there not any better examples out there? Can someone with understanding contribute a few? How to get gRPC Async and Async Streaming are a complete mystery to me. On Friday, October 30, 2020 at 5:18:59 PM UTC-4 [email protected] wrote: > I don't believe it does leak due to the 'delete this;' > <https://github.com/grpc/grpc/blob/v1.33.1/examples/cpp/helloworld/greeter_async_server.cc#L115> > > at the end of the CallData state machine. Though, I agree this is not the > best example. It's a bit tenuous to rely on classes to delete themselves. > It would be easy to lose track and leak a CallData in error scenarios or > with a more complex state machine. > > Aaron > > On Friday, October 30, 2020 at 8:44:06 AM UTC-7 [email protected] > wrote: > >> The example at >> >> https://github.com/grpc/grpc/blob/v1.33.1/examples/cpp/helloworld/greeter_async_server.cc >> >> has blatantly obvious memory leaks. If CallData allocates itself when >> proceed is called, there is no way for it to clean up the new instance when >> the server is shutting down. Also, the CallData that is allocated before >> the loop even begins can't be cleaned up, since no pointer to it is stored. >> I guess the example just doesn't care, as it assumes the process is just >> going to abort. However, trying to make sense of CallData, its states, and >> how we would do it in the real world isn't obvious with the example in this >> state. >> >> Is there one that doesn't blatantly leak? >> > -- 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/2c40acd8-8b17-4cdf-8eac-958be7f31d95n%40googlegroups.com.
