[Mesa-stable] [Mesa-dev] [PATCH] ralloc: Use __attribute__((destructor)) instead of atexit(3)

[Jose Fonseca]

On 11/09/15 00:35, Erik Faye-Lund wrote:
> On Mon, Sep 7, 2015 at 3:54 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
>> On 07/09/15 10:17, Jean-Sébastien Pédron wrote:
>>>
>>> On 04.09.2015 01:37, Matt Turner wrote:
>>>>
>>>> You need to test for this support in configure.ac. It's as simple as
>>>> adding a call to AX_GCC_FUNC_ATTRIBUTE in the existing alphabetized
>>>> list and then a little bit of preprocessor in src/util/macros.h.
>>>
>>>
>>> Should the code fallbacks on atexit(3) if the attribute is not
>>> supported?
>>
>>
>> At least on Windows, with MSVC,  atexit should be the right thing to do,
>> since we statically link MSVC RunTime,
>>
>>
>>> Can I use the HAVE_FUNC_ATTRIBUTE_DESTRUCTOR macro in
>>>
>>> ralloc.c for this purpose?
>>
>>
>>
>>
>>
>> For the record, another alternative (way more portable), is you have a
>> simple .cpp file with a static destructior:
>>
>>
>>    class AtExit
>>    {
>>    public:
>>       ~AtExit() {
>>           // do what must be done
>>        }
>>    };
>>
>>    AtExit atExit();
>>
>>
>> After all, it seems wrong to use non-standard C to replicate what standard
>> C++ can do.
>
> That sounds nice and all, until you stumble over problems like
> STB_GNU_UNIQUE, which makes renders C++ static destructors completely
> unusable on Linux if you have even a single static variable in a
> method in your C++ code.
>
> Read up on it on  Read
> http://gcc.gnu.org/ml/gcc-help/2011-05/msg00450.html if you feel like
> being depressed.
>

I read up to https://gcc.gnu.org/ml/gcc-help/2011-05/msg00450.html but 
it sounded like a problem in dlclose.

 > Unfortunately, C++ and it's many questionable implementations make up
 > an unpredictable beast that keeps on throwing curve-balls that makes
 > it no fun at all for library development.

The irony is that, __attribute__((destructor)) is one of those sources 
of unpredictability (the order destructors gets called is almost 
unpredictable), which is probably why it was never added to standard C.

I can't look at using C with non-standard extensions on a good light, 
and using extended C (ie, C++) under a bad light.  Using and abusing 
non-standard extensions will surely throw curve-balls too.  At least 
those curve-balls threw by C++ are shared by a lot of other people, more 
likely to get sorted out without our intervention.


Finally, dlclose'ing shared objects is inherently like walking on a mine 
field, no matter what language one uses.  IMHO, if we can't support 
dlclose safely/robustly, might as well slap -Wl,-z,nodelete on our 
shared objects, ie. just pretend everything was statically linked.


Jose