Commit graph

3 commits

Author SHA1 Message Date
21fdce0dfc a better solution to reject out-of-order static access after shutdown
Static initialisation and shutdown can be intricate; but in fact they
work quite precise and deterministic, once you understand the rules
of the game.

In the actual case at hand the ClassLock was already destroyed, and
it must be destroyed at that point, according to the standard. Simply
because it is created on-demand, *after* the initialisation of the
static DependencyFactory, which uses this lock, and so its destructor
must be called befor the dtor of DependencyFactory -- which is precisely
what happens.

So there is no need to establish a special secure "base runtime system",
and this whole idea is ill-guided. I'll thus close ticket #1133 as wontfix

Conflicts:
	src/lib/dependable-base.hpp
2018-04-01 04:52:50 +02:00
a8273283d1 (WIP) fruitless efforts to build a dependable static environment
My gut feeling tells me that I am on the wrong track alltogether
2018-04-01 04:52:01 +02:00
f0eeafddaa Identified some problems regarding static destruction
When some dependency or singleton violates Lumiera's policy regarding destructors and shutdown,
we are unable to detect this violation reliably and produce a Fatal Error message.
This is due to lib::Depend's de-initialisating being itself tied to template generated
static variables, which unfortunately have a visibility scope beyond the translation unit
responsible for construction and clean-up.
2018-03-31 17:27:13 +02:00