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

[Ian Romanick]

On 09/10/2015 05:29 AM, Jose Fonseca wrote:
> On 10/09/15 02:54, Ian Romanick wrote:
>> On 09/07/2015 06:54 AM, Jose Fonseca 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:
>>
>> Arg. :(  We used to have code that used this in several places, but that
>> idiom has gradually been removed.  See c61bc6ed (although that was using
>> a constructor to initialize instead of a destructor to free).  I don't
>> care too much what idiom we pick, but I think we should pick one and
>> stick with it.
> 
> It's not necessary to do it in several places, at least for the
> destructor -- we could have a single C++ module inside src/util, which
> provided a "dl_atexit".
> 
> I don't feel too strongly either way, but my impression is that the
> hassle of doing this with non-standard vendor-specific C extensions is
> greater than having a small C++ file somewhere.

Like I said, I don't care how we solve the problem.  The only thing I
don't want is to do it one way now, then in six months have someone say,
"Ew" and change to some other way that could have been used in the first
place.  I really annoys me when we have təˈmeɪtoʊ / təˈmɑːtoʊ churn.

If we're going to pick a way, we should document that way in
docs/devinfo.html so as to significantly raise the bar for someone
wanting to flip to a different, roughly equivalent method.  We should
also document the reason for picking the particular method.

> For the constructor problem, we could just rely on the standard C11
> once_flag/call_once.

That's basically what c61bc6ed does.  It calls an initializer function
from core Mesa's one_time_init function.  It could probably be moved
into the implementation of _mesa_strtof, and that would eliminate the
need to call the initializer from the standalone preprocessor and the
standalone GLSL compiler.

Any idea how much overhead is call_once adds on the second and later
calls?  I seem to recall the pthread_once still adds noticeable
overhead... but that recollection is from ages ago.

> Jose