[lldb-dev] Use of function local statics

[Zachary Turner]

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.


On Thu, Aug 21, 2014 at 10:09 AM, Zachary Turner <zturner at google.com> wrote:

> 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:
>
> // HostInfoBase.h
> class HostInfoBase
> {
> public:
>     static void Initialize();
>
> private:
>     static HostInfoFields *m_fields;
> };
>
> // HostInfoBase.cpp
>
> struct HostInfoFields
> {
>     uint32_t m_number_cpus;
>     std::string m_lldb_shared_library_path;
>     // etc
> };
>
> HostInfoFields *HostInfoBase::m_fields = nullptr;
>
> void HostInfoBase::Initialize()
> {
>     m_fields = new HostInfoFields();
> }
>
> // lldb-main.cpp
> int main(int argc, char **argv)
> {
>     HostInfo::Initialize();
> }
>
>
> Thoughts?
>
>
> On Thu, Aug 21, 2014 at 10:03 AM, Greg Clayton <gclayton at apple.com> wrote:
>
>>
>> > On Aug 20, 2014, at 2:36 PM, Zachary Turner <zturner at google.com> wrote:
>> >
>> > 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.
>> >
>> > 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.
>> >
>> > 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.
>> >
>> > Thoughts?
>>
>> 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.
>>
>> I would suggest using std::once for any issues you run into:
>>
>> static std::once_flag g_once_flag;
>> std::call_once(g_once_flag, [](){
>>     // Insert code here to run once in a thread safe way
>> });
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140821/a8de83a6/attachment.html>