Ichthyostega 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
..
ArchitectureSummary.txt	fix menu entry	2011-03-31 20:50:33 +02:00
ETD.txt	release prep: clean-up obsolete information	2015-11-02 21:14:24 +01:00
index.txt	DI: document the reworked Singleton / Dependency-Factory	2018-03-25 09:33:57 +02:00
playRender.txt	DOC: player architecture, language corrected.	2013-01-08 02:16:48 +01:00
Subsystems.txt	a better solution to reject out-of-order static access after shutdown	2018-04-01 04:52:50 +02:00
TimeQuant.txt	Documentation: integrate the time quantisation concept pages	2012-10-10 05:18:46 +02:00
TimeUsage.txt	Documentation: integrate the time quantisation concept pages	2012-10-10 05:18:46 +02:00