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

[Erik Faye-Lund]

On Thu, Sep 10, 2015 at 7:58 PM, Ian Romanick <idr at freedesktop.org> wrote:
> On 09/10/2015 05:29 AM, Jose Fonseca wrote:
>> On 10/09/15 02:54, Ian Romanick wrote:
>>
>> 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.

My two cents would be that we should "bootstrap" the init and deinit
from one well-known point into some functions (perhaps exactly
one_time_init / one_time_fini?) that takes care about bringing up/down
the rest of mesa (like suggested above). That'd make it easy to have
different systems do different init without having to riddle the rest
of mesa with details about how we figure out when this happens.

For instance, on Windows you have DLL_PROCESS_ATTACH and
DLL_PROCESS_DETACH calls to DllMain() where this can easily be done.
And on most Unix-systems, you can use __attribute__((destructor)) etc.

I just think it's kinda awful to leak these details directly into
places like ralloc. I don't think these subsystems should need to know
when they are deinitialized, only how they are.

>> 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.

AFAIK, it involves stuff like memory barriers, which you really don't
want mixed up in your shader-code parsing. Committing caches to memory
just to grok a float is a bit of a steep price to pay. I did consider
this approach, but decided against it for these reasons.

Of course, it might turn out that I'm overly wary, and someone
profiles it only to show no real world problem, dunno.