> On May 28, 2014, 8:14 p.m., Andrew Stitcher wrote: > > I don't understand your comment about not changing the static variables to > > class members, as function statics will be duplicated in any forking > > process in exactly the same way. > > > > Function statics are really the same executable layout-wise as globals but > > they are only in scope in the function itself. The only difference is that > > for function statics that are a class type there will be some extra state > > and code to ensure that it is constructed thread safely only once (at least > > this is true for gcc and since C++11). > > Gordon Sim wrote: > Ah, I assumed that the static locals would be initialised when they first > came into scope. If that is not the case then I agree there is no advantage. > I actually have a patch with them as member variables as that is what I > started with. I'll upload that. > > Andrew Stitcher wrote: > TBH I would leave the lock as a function static, and move the boolean > (and use it in the destructor) > > Gordon Sim wrote: > What's the thinking behind that?
Keeping the member as encapsulated as possible: the lock is only used in the function so keep it there - I'm suggesting that the boolean should also be used to not call shutdownNSS() if NSS did not initialise so it would need to be a class member, if not for sharing the boolean with the destructor I'd keep it static in the initialise function. - Andrew ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21978/#review44159 ----------------------------------------------------------- On May 28, 2014, 7:51 p.m., Gordon Sim wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/21978/ > ----------------------------------------------------------- > > (Updated May 28, 2014, 7:51 p.m.) > > > Review request for qpid and Andrew Stitcher. > > > Bugs: QPID-5788 > https://issues.apache.org/jira/browse/QPID-5788 > > > Repository: qpid > > > Description > ------- > > Delay initialisation of NSS until the first SSL connection is created. This > allows env vars to be set programmatically if desired and allows forking > (provided connections are created *after* forking). > > > Diffs > ----- > > /trunk/qpid/cpp/src/qpid/client/SslConnector.cpp 1597730 > > Diff: https://reviews.apache.org/r/21978/diff/ > > > Testing > ------- > > make test passes > > The two test cases described in the JIRA work as expected > > > Thanks, > > Gordon Sim > >
