[cfe-dev] [RFC] Suppress C++ static destructor registration

[Craig, Ben via cfe-dev]

There are guaranteed semantics for global destruction for well behaved 
programs.  First, thread locals are destroyed in LIFO order.  Then 
function level statics are destroyed in LIFO order. Then global and 
class statics are destroyed.

Here are some stackoverflow responses (with links to standardese) that 
can be useful:
http://stackoverflow.com/questions/16010083/order-between-destruction-of-global-object-and-atexit-in-c
http://stackoverflow.com/questions/38130185/is-it-legal-to-initialize-a-thread-local-variable-in-the-destructor-of-a-global

One area that I'm not clear on (and maybe this is what prompted your 
post) is what happens with regards to detached threads and global 
destruction.  To be honest, I think those programs (and detached threads 
in general) are broken for clean program termination use cases.

I'm not opposed to adding -fno-cxx-static-destructors... but I disagree 
with your current justifications.  Provide some concrete examples.

On 7/18/2016 3:39 PM, Bruno Cardoso Lopes via cfe-dev wrote:
> Hi,
>
> C++ static destructors can be problematic in multi-threaded
> environment. Some of the issues users often complain about include:
> 1. Teardown ordering: crashes when one thread is exiting the process
> and calling destructors while another thread is still running and
> accessing the destructing variables
> 2. Shared code that is compiled both as an application and as a
> library. When library mode is chosen, goto (1).
> 3. Some projects currently override __cxa_atexit to avoid the behavior
> in question.
>
> To get around that, I propose we add a compiler option (e.g.
> -fno-cxx-static-destructors) to allow clang to suppress destructor
> registration (currently done via __cxa_atexit, atexit):
> https://reviews.llvm.org/D22474
>
> I'm opening this discussion here on cfe-dev to get some feedback on the matter
>
> One can argue that dealing with C++ static destructors in
> multi-threaded environment is solely the responsibility of the
> developer, however since (AFAIK) we don't have any standard guaranteed
> semantic for "global destruction vs. threads", it seems fair to me
> that we could give developers some option.
>
> Cheers,
>

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project