NEW174747
[CMake] Specify -fno-threadsafe-statics 
https://bugs.webkit.org/show_bug.cgi?id=174747
Summary [CMake] Specify -fno-threadsafe-statics
Yusuke Suzuki
Reported 2017-07-21 22:06:28 PDT
Our WebKit tree assumes this option is specified.
Attachments
Add attachment proposed patch, testcase, etc.
Michael Catanzaro
Comment 1 2017-07-22 09:01:43 PDT
What, why? Developers expect initialization of statics to be threadsafe. Why add this massive footgun?
Yusuke Suzuki
Comment 2 2017-07-22 09:18:07 PDT
(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.
Darin Adler
Comment 3 2017-07-22 10:39:12 PDT
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.
Michael Catanzaro
Comment 4 2017-07-22 11:35:27 PDT
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....
Darin Adler
Comment 5 2017-07-23 13:15:41 PDT
(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.
Fujii Hironori
Comment 6 2018-02-02 14:17:51 PST
According to the crash log of Bug 182104, GTK port seems to rely on threadsafe-statics so far.
Fujii Hironori
Comment 7 2018-02-06 05:07:25 PST
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.
Don Olmstead
Comment 8 2018-05-02 11:27:42 PDT
Yusuke is this something we could potentially codify into a clang-tidy rule so we could turn off thread safe locals?
Note You need to log in before you can comment on or make changes to this bug.