Hi, I have looked at the gRFC and not too sure how it fixes some of the current issues with library shutdown (you referenced the issues I mentioned on GitHub/private conversations).
First off, I don't know about other users but I was already forced to use grpc_init/shutdown in my code (so I am aware of those functions). In my app, I am setting the tracers using tracer api and the tracers are only enabled if the grpc_init is called first. So when the application boots up and I configure my logging, I needed to call grpc_init before doing anything with server instantiation etc. The main problem I have is I feel like the current apis require too much management from the integrator and still not 100% safe. In my setup, I use async api. My main thread processes events/tags while I have a separate thread to pump the completion queue. Now, suppose I want to shutdown my server instance. Currently, I can’t call grpc::Server::Shutdown without making sure that all my existing events in progress are finished first and I have destroyed every reference to all the library objects (say ServerContext which theoretically should be independent of server life time) . However, without calling grpc::Server::Shutdown, my server may keep on getting new events from new clients requesting new rpcs. It’d be much easier if I had an api that could allow me to cancel pending rpcs (the ones that have not been started yet). At the moment, only way for me to do this would be to keep a list of rpcs that have not started and manually call serverContext->TryCancel on them. Are you suggesting that with new flow, I can simply call grpc::server::Shutdown, have it cancel all the pending rpcs/events (some of which can cause freeing of additional resources like ServerContext) and the things that are attaching their lifetime to server would instead hang on to the GrpcLibrary? Thanks. On Tuesday, December 19, 2017 at 3:48:40 PM UTC-8, Yang Gao wrote: > > Users reported bugs related to this issue. Some of the issues can be > avoided/worked around by strengthening the requirement or minor tweaks of > the code. > Some are not so easy to fix without potential performance overhead. The > internal doc contains a couple of more links of related issues people > encountered. > > On Tue, Dec 19, 2017 at 3:24 PM, 'Vijay Pai' via grpc.io < > [email protected] <javascript:>> wrote: > >> Hi there, >> >> I'd very much like to discuss this issue. Switching to explicit >> initialization increases friction for users, but keeping it the existing >> way just increases friction for the library writers (unless the code ends >> up being so failure-prone that it affects users through a loss of >> stability). Has there been a user feature request for explicit >> initialization? >> >> >> On Tuesday, December 12, 2017 at 9:40:21 AM UTC-8, Yang Gao wrote: >>> >>> Hi, >>> >>> I have created a gRFC in https://github.com/grpc/proposal/pull/48 which >>> will add a new C++ class to make gRPC C++ library lifetime explicit. >>> If you have comments and suggestions, please use this thread to discuss. >>> Thanks. >>> >> -- >> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/grpc-io. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/grpc-io/79d883f9-cbc3-4281-9c16-3f5b7edaff3e%40googlegroups.com >> >> <https://groups.google.com/d/msgid/grpc-io/79d883f9-cbc3-4281-9c16-3f5b7edaff3e%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/fd79a64c-048a-4dd5-9d2b-ae7256009e40%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
