Our WebKit tree assumes this option is specified.
What, why? Developers expect initialization of statics to be threadsafe. Why add this massive footgun?
(In reply to Michael Catanzaro from comment #1) > What, why? Developers expect initialization of statics to be threadsafe. Why > add this massive footgun? It turns out that Apple ports use this option right now. Thus code which may be used in Apple port should assume this model. I think this divergence is bad: Consider the case writing a new WTF module which is used in GTK ports. This module will be written by the model that statics init is threadsafe. Once this is used in Apple ports too, we have a bad time. We should not have different mental model for such a foundental semantics. Both sides are OK to me. Personally I think not using this model even in Apple ports are better. Anyway, we should have the same semantics for this across the all ports.
WebKit has been built with non-threadsafe statics since the first year of the project. It’s possible that on non-Apple ports this was never done before, though. If we can achieve high performance without that optimization, and make our programming easier and safer, that would be great. But doing that would require some experimentation and performance analysis. If not, I think that being consistent across ports is likely to boost performance on the non-Apple ports which are paying a higher price in any function that has a static in it. And I agree with Yusuke that we there are benefits to having the same semantics across platforms.
OK... but this is going to introduce bugs, because no doubt our code makes the opposite assumption. And those bugs are going to be very hard to track down. This is unfortunate, but that's life as long as we have two different build systems. In other news, Visual Studio has native support for CMake now....
(In reply to Michael Catanzaro from comment #4) > that's life as long as we have two different build systems I’m sorry to be argumentative, but this has very little to do with different build systems! It has to do with different optimization choices made on different platforms.
According to the crash log of Bug 182104, GTK port seems to rely on threadsafe-statics so far.
Never mind my comment 6. Bug 182494 changed GC thread not to call RunLoop::current() anymore. No race condition between main thread and GC thread in constructing NeverDestroyed.
Yusuke is this something we could potentially codify into a clang-tidy rule so we could turn off thread safe locals?
https://docs.microsoft.com/en-us/cpp/build/reference/zc-threadsafeinit-thread-safe-local-static-initialization?view=vs-2019 For MSVC flag.