Hi Arpit, grpc_init initializes OpenSSL for a short period (~2 days) and the code was later removed. Do you still the problem, if you fetch the latest master?
On Monday, April 16, 2018 at 2:22:32 PM UTC-7, Arpit Baldeva wrote: > > Hi, > > I recently pinned down a sporadic race condition in my application due to > grpc intializing OpenSSL internally. The problem is that OpenSSL has some > global callbacks that grpc is trying to initialize on it's own without the > authorization of the application. The problem is in the > init_openssl call in ssl_transport_security.cc which trounces similar > calls from the application. The situation is made worse(race condition) if > some application threads already have locks acquired via previous calls and > then grpc changes the stuff underneath before the locks are released (hence > the race condition). > > My application has usage of OpenSSL in a wider context than just grpc. I > get the point that grpc is wrapping this up to make it easier for standing > up an application with grpc but I think such type of things should be > accompanied by a compile/run time option supplied at grpc_init that let's > application decide the right owner. I am fine with the option defaulting to > grpc initializing the OpenSSL internally. > > Thoughts? > > 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/msgid/grpc-io/167b2372-534d-430c-b66e-443f0185afba%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
