[boost] Solving Robert's singleton problem (was: Re: "peer reviewed" - Rights and responsibilities of maintainers)

On 18/10/2018 08:52, Olaf van der Spek via Boost wrote:

...

On Wed, Oct 17, 2018 at 9:06 AM, Alexander Grund via Boost wrote:

...

b) In the case I described and tested with #111 (and now even with #128) There are 2 shared libraries with their own instances of the singletons (this can be checked by debugging the ctor/dtor of them). The lifetime mismatch happens due to "some linux mechanism" destroying same types from different libraries at the same time invalidating the expectation of each library. Example (actually witnessed by printf-debugging) Using static libs in shared libs is a recipe for disaster isn't it?

Rather than criticising Robert's maintainership, can we maybe spend more effort instead on how to best to solve his problem? I in the past have faced the problem where: 1. There must be a complex singleton instantiated in unknowable compilation units. 2. I don't control what weird linker flags the end user uses, or what combination of shared and static libraries they might use with me in each of them. 3. Code may use me during the shared library bootstrap and eviction process i.e. during static data init/deinit of plugins being dynamically loaded and evicted. The way I have solved this problem is brutal, but it works. In my singleton constructor, I create a named shared memory area unique to my process. In that named shared memory area, I store a pointer to myself, and nothing else. When future singletons get constructed, they reopen the same named shared memory area, realise they are a second or third or fourth instance, and redirect themselves to use the original singleton. They add their own address to the shared memory area. When a shared library containing the original singleton gets dynamically kicked out, it asks the next singleton in the list of singletons in the shared memory area to take over. It transfers all its contents to the new master singleton, and the shared memory list is updated. I appreciate how brutal and overkill this solution is. However, it solves the problem well, in perpetuity, and under whatever crazy weird settings or use cases any user could think of. Niall