<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 7/19/2016 9:11 AM, Reid Kleckner via cfe-dev wrote:<br>
<blockquote
cite="mid:CACs=tyKbG6k2JxzGvKc8R169bfVMDosaK9h5rhPx4MOyWhkdsw@mail.gmail.com"
type="cite">
<div dir="ltr">I also don't like subsetting the language even more
(-fno-exceptions, -fno-rtti, -fno-sized-allocation, etc), but
this is another one of those C++ features that really isn't "pay
for what you use".
<div><br>
</div>
<div>The simplest way to avoid paying for static destruction is
to turn it off completely.</div>
</div>
</blockquote>
This seems *exactly* like pay for what you use. If you have no
static destructors, you don't pay anything. It's just easy to use
this feature accidentally, and when you probably shouldn't.<br>
<br>
With RTTI and exceptions, you get object code increases even if your
code can't possibly throw, and never uses dynamic_cast or typeid.
To the best of my knowledge, there is no code size increase if you
don't have a static destructor.<br>
<br>
I can see this as a usability improvement. Say I have a class that
is generally not a global, and it needs a ctor and dtor for those
cases. Now I want the ctor to run at program / dynamic library
initialization. This flag can make that easier to do, without
dragging along the dtor as well. It has maintenance costs though.<br>
<br>
I will agree that this has a similar feeling to the issues behind
std::thread's destructor problems (terminate, join, or detach?). In
a single threaded world, running static destructors seems like a
reasonable thing to do, and generally doesn't introduce stability
problems. In a multi-threaded world, there doesn't seem to be a
safe thing to do in the general case. Destroying the objects cause
problems. We can't wait for all the other threads to finish, we
can't terminate those threads, we can't freeze them. The standard
doesn't talk about shared libraries either, so that makes things
worse.<br>
<br>
<br>
<blockquote
cite="mid:CACs=tyKbG6k2JxzGvKc8R169bfVMDosaK9h5rhPx4MOyWhkdsw@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Jul 18, 2016 at 5:08 PM,
Richard Smith via cfe-dev <span dir="ltr"><<a
moz-do-not-send="true"
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 1:39 PM, Bruno Cardoso Lopes via cfe-dev <span
dir="ltr"><<a moz-do-not-send="true"
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">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 moz-do-not-send="true"
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.</blockquote>
<div><br>
</div>
</span>
<div>They already have options. They can use
std::quick_exit, which was added specifically to
address this problem, if they don't want destructors
to be run at all. There are standard techniques to
avoid destructors being run for specific objects:</div>
<div><br>
</div>
<div> template<typename T> union not_destroyed
{</div>
<div> T value;</div>
<div> template<typename ...U> constexpr
not_destroyed(U &&...u) :
value(std::forward<U>(u)...) {}</div>
<div> ~not_destroyed() {} </div>
<div> };</div>
<div> not_destroyed<std::string> my_str("foo");
// technically has object lifetime issues</div>
<div><br>
</div>
<div> ... or ...</div>
<div><br>
</div>
<div> std::string &&s = *new
std::string("foo");</div>
<div><br>
</div>
<div>Are these options not good enough? Is per-TU
control (with no source changes) a goal here, or is
it more of an incidental property of the solution?
It seems to me that we should prefer to either push
people towards the standard std::quick_exit solution
or propose an alternative standard mechanism rather
than invent our own proprietary way to work around
this problem.</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
</pre>
</body>
</html>