Hi Arpit, You did not mention you use grpc_init() before. My understanding of the crash you saw at the destruction of ServerContext is that you have no more grpc_init() covering at that point. And you deleted the server before destroying the ServerContext (rather than just shutdown the server). If that is not the case, then I think my previous thought was not right.
On Wed, Dec 20, 2017 at 11:33 AM, Arpit Baldeva <[email protected]> wrote: > 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]> 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]. >>> 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/ms >>> gid/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 > <https://groups.google.com/d/msgid/grpc-io/fd79a64c-048a-4dd5-9d2b-ae7256009e40%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/CAB1HKY7yXzyAmPZUNoqhB0hpTCZ0A86atBkGJVNNiuSrNxuE-w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
