<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 18, 2016 at 6:46 PM, Richard Smith via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Jul 18, 2016 at 5:37 PM, James Knight via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That sounds like a nice idea. The standards-required behavior of tearing down globals is insane, and it'd sure be nice to be able to easily opt out of the insanity. It'd be nicest if it was supported in both GCC and Clang with the same flag, of course. :)<br>
<br>
std::quick_exit is just about worthless, because there's just about no practical way that you can ever get all the code linked into your binary to stop calling exit().<br></blockquote><div><br></div></span><div>Recompiling all the code linked into your binary with a custom compiler flag is also not the most practical thing to ask of people. Maybe a more practical approach would be to register an atexit handler that calls quick_exit? :)</div><span class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
IMO, the standard should just entirely remove the utterly broken global destructors "feature".<br></blockquote><div><br></div></span><div>Perhaps so, but creating a non-standard dialect of C++ with different semantics has historically proven to not be a viable way to get that effect. This change will create portability headaches down the line, as other flags to turn off parts of standard C++ semantics have done (-fno-rtti, -fno-exceptions).</div></div></div></div></blockquote><div><br></div><div>To be clear, even on PS4, we would not default this flag to on, as there are use cases that do exit. It would just be something that we suggest users to try if it makes sense for them.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> And evidence from those suggests that the standard never does actually get fixed, and each vendor ends up with a slightly different mode.</div><div><br></div><div>If someone's prepared to write up a paper for the C++ committee exploring what it would mean to standardize this behaviour and actually fix the problem for everyone, it would seem extremely reasonable for clang trunk to carry a flag to enable that behaviour (and it certainly doesn't have to wait for the committee to respond).</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In the "interim", a compiler flag is nice because you can set it in your build system, and all your existing code just starts working better (where better = fewer random unreproducible crashes on shutdown when someone accidentally used a global with a destructor). And you don't ever have to worry about this problem again...</blockquote><div><br></div></span><div>... until you try to use a library that depends on a global destructor running on program shutdown :) For previous similar flags, there was a small but perpetual cost paid by every compiler vendor and by users, for each of these features that got into mainstream use -- and I expect this *will* enter mainstream use (it would be a very convenient solution to a selection of important problems).</div><div><div class="h5"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
> On Jul 18, 2016, at 4:39 PM, Bruno Cardoso Lopes via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> C++ static destructors can be problematic in multi-threaded<br>
> environment. Some of the issues users often complain about include:<br>
> 1. Teardown ordering: crashes when one thread is exiting the process<br>
> and calling destructors while another thread is still running and<br>
> accessing the destructing variables<br>
> 2. Shared code that is compiled both as an application and as a<br>
> library. When library mode is chosen, goto (1).<br>
> 3. Some projects currently override __cxa_atexit to avoid the behavior<br>
> in question.<br>
><br>
> To get around that, I propose we add a compiler option (e.g.<br>
> -fno-cxx-static-destructors) to allow clang to suppress destructor<br>
> registration (currently done via __cxa_atexit, atexit):<br>
> <a href="https://reviews.llvm.org/D22474" rel="noreferrer" target="_blank">https://reviews.llvm.org/D22474</a><br>
><br>
> I'm opening this discussion here on cfe-dev to get some feedback on the matter<br>
><br>
> One can argue that dealing with C++ static destructors in<br>
> multi-threaded environment is solely the responsibility of the<br>
> developer, however since (AFAIK) we don't have any standard guaranteed<br>
> semantic for "global destruction vs. threads", it seems fair to me<br>
> that we could give developers some option.<br>
><br>
> Cheers,<br>
><br>
> --<br>
> Bruno Cardoso Lopes<br>
> <a href="http://www.brunocardoso.cc" rel="noreferrer" target="_blank">http://www.brunocardoso.cc</a><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div></div></div><br></div></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>