function-level static initialization

[Kevin Bailey]

I noticed that we disable thread-safe function-level static initialization in the Linux builds. I can't imagine a good reason for doing this - there's no performance hit - so I assume it is to align with the VS2013 build. Even then, it is risky, since we are counting on TSAN to catch accidental inclusions. By "accidental inclusion", I'm referring to someone unknowingly having a static symbol that has a non-POD constructor or gets changed to have one after the fact.

If consistency is the reason, will we be changing this flag when we stop using VS2013? If it's not, I'd be curious to hear the reason.

thx,

krb

https://msdn.microsoft.com/en-au/library/hh567368.aspx#concurrencytable

[Scott Hess]

https://www.chromium.org/developers/coding-style/cpp-dos-and-donts#TOC-Static-variables

"Dynamic initialization of function-scope static variables is thread-unsafe in chromium, even on compilers/platforms such as gcc/linux where such idioms are normally safe."

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Mark Mentovai]

This was done because we had one platform (MSVS) which couldn’t do thread-safe static initialization at all. Since we couldn’t use it there, we made our other platforms match.

Since then, thread-safe static initialization has been standardized in C++11, and eventually, MSVS caught up with the times.

In light of our switch to MSVS 2015, which does properly support thread-safe static initialization, I wonder if we can lift this restriction and write now-standard C++.

[Nico Weber]

Yes, once 2015 sticks we should revisit this. So far, the tree isn't a fan of 2015 though :-)