On Thu, 20 Oct 2016, Bartłomiej Święcki wrote:
Hi Bartłomiej,
WRT the function-returning static trick, yep, it should work as you
describe. I believe Scott Meyers popularized this "static singleton"
trick. I pretty much abhorr singletons, but it's super handy way to
mitigate the "unordered initialization fiasco", which is exactly wher e
you're going here.
IIRC this should also ensure that destructors are called when unloading
the module, not 100% sure about that though.
I seem to remember this biting me, so checked-- it's a "fun" answer: from
what I can see, the C++ standard says nothing about it, and furthermore
the POSIX standard doesn't require specific behavior from dlclose(). In
practice, it probably will happen, but it's not reliable behavior. (But,
see below.)
I suppose that means the way to go is to write a finalizer (perhaps put
both that, and the mutable singleton-function in a shared namespace to
keep them together but make it clear there's no class behavior, and then
for "const" data, make the finalizer a friend) and calling it before the
module is unloaded. Imagine this now requires some locks, since the data's
mutable.
I mentioned this to Bartłomiej in a PM, and he pointed out that if the
module consumer can be sure that nothing's using the memory pools at the
point of unloading, locking could be avoided. As long as that guarantee
holds, I agree.
I hope that's helpful,
-Jesse
Also:
The manpage (3 dlopen) has an interesting note under the heading
"Initialization and finalization functions"-- there are some extensions
for a sort of constructor/destructor mechanism, and some interesting notes
about _init() and _fini() that are worth reading.
