LUMIERA.clone/wiki
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
..
draw DOC: drawing to show the structure of timeline display 2016-12-02 04:07:46 +01:00
DIR_INFO update some DIR_INFO entries 2011-04-05 00:44:30 +02:00
empty.html upgrade TiddlyWiki to v2.8.1 2013-08-10 05:36:57 +02:00
InterfaceConcept_Varga.mm Lumiera GUI thoughts -- Mindmap to complement the Interface concept PDF 2015-04-26 23:22:42 +02:00
renderengine.html DI: document the reworked Singleton / Dependency-Factory 2018-03-25 09:33:57 +02:00
thinkPad.ichthyo.mm a better solution to reject out-of-order static access after shutdown 2018-04-01 04:52:50 +02:00
uml better use doc/devel/uml... 2007-06-21 02:57:49 +02:00
workflow.mm DOC: expand concept map 2014-10-25 01:56:44 +02:00