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

Subject: [boost] Solving Robert's singleton problem (was: Re: "peer reviewed" - Rights and responsibilities of maintainers)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-10-18 20:19:11

> 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
>> <boost_at_[hidden]> 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