<div dir="ltr">Thanks.  I will submit another patch first (which adds more global statics), and then fix this in a follow-up patch.  It's easier to do it that way rather than submit the fix first and deal with the merge conflict that would arise.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 21, 2014 at 10:28 AM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We already have global place for intialization:<br>
<br>
lldb_private::Initialize ()<br>
<br>
This is in lldb.cpp. Feel free to add a HostInfoBase::Initialize() to this function. This will solve your problems.<br>
<span class="HOEnZb"><font color="#888888"><br>
Greg<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Aug 21, 2014, at 10:10 AM, Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br>
><br>
> BTW, another problem with std::call_once is that, like thread-safe function local statics as well, any kind of thread synchronization is undesirable if it can be avoided.<br>
><br>
><br>
> On Thu, Aug 21, 2014 at 10:09 AM, Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br>
> std::call_once would solve the problem, but it's also going to be ugly putting that all over the place.  Another potential solution is to do something like this:<br>
><br>
> // HostInfoBase.h<br>
> class HostInfoBase<br>
> {<br>
> public:<br>
>     static void Initialize();<br>
><br>
> private:<br>
>     static HostInfoFields *m_fields;<br>
> };<br>
><br>
> // HostInfoBase.cpp<br>
><br>
> struct HostInfoFields<br>
> {<br>
>     uint32_t m_number_cpus;<br>
>     std::string m_lldb_shared_library_path;<br>
>     // etc<br>
> };<br>
><br>
> HostInfoFields *HostInfoBase::m_fields = nullptr;<br>
><br>
> void HostInfoBase::Initialize()<br>
> {<br>
>     m_fields = new HostInfoFields();<br>
> }<br>
><br>
> // lldb-main.cpp<br>
> int main(int argc, char **argv)<br>
> {<br>
>     HostInfo::Initialize();<br>
> }<br>
><br>
><br>
> Thoughts?<br>
><br>
><br>
> On Thu, Aug 21, 2014 at 10:03 AM, Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br>
><br>
> > On Aug 20, 2014, at 2:36 PM, Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br>
> ><br>
> > As part of my moving code from Host to HostInfo, I moved some function-local statics to global class-member statics.  The reason for this is that MSVC doesn't support thread-safe function local statics until VS2014, which is still only in technology preview, whereas LLVM, clang, and by extension LLDB support building as far back as VS2012.<br>

> ><br>
> > Greg submitted r216080 to convert these global statics back to function-local statics, but this had a bug in it which broke things for all platforms, so I reverted it in r216123.  A simple fix would have just been to address the bug, but my original transition from function-local statics to global statics was intentional due to the fact that any use of them on a non-primitive type is undefined behavior on MSVC.<br>

> ><br>
> > So, I want to see if people have a strong preference one way or the other.  If the issue is just silencing the compiler warning that clang gives about global constructors, then we can do that in CMake and/or the Xcode project.  On the other hand, I understand that global static constructors increase application startup times.  Is this a concern for anyone?  If so, I can try to come up with a solution.  I think if we try to keep the use of statics to a minimum, and make sure that they are generally simple types (e.g std::string, which simply does a malloc), then there should be no noticeable performance impact on startup.<br>

> ><br>
> > Thoughts?<br>
><br>
> For our build submissions here at Apple we need to keep the number of global constructors to a minimum. We need to apply for exceptions for each global constructor that is added to a shared library or framework. This is the main reason for the change I made. global constructors are fine for apps and they get to make that decision, but for shared libraries, they should be avoided if possible.<br>

><br>
> I would suggest using std::once for any issues you run into:<br>
><br>
> static std::once_flag g_once_flag;<br>
> std::call_once(g_once_flag, [](){<br>
>     // Insert code here to run once in a thread safe way<br>
> });<br>
><br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>