benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
lumiera_/src/lib/zombie-check.hpp

99 lines
2.4 KiB
C++
Raw Normal View History

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
/*
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:43:43 +02:00
ZOMBIE-CHECK.hpp - flatliner self-detection
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
Copyright (C) Lumiera.org
2018, Hermann Vosseler <Ichthyostega@web.de>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
/** @file dependable-base.hpp
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:43:43 +02:00
** Detector to set off alarm when (re)using deceased objects.
(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 03:41:41 +02:00
** @see sync-classlock.hpp
** @see depend.hpp
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
*/
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:43:43 +02:00
#ifndef LIB_ZOMBIE_CHECK_H
#define LIB_ZOMBIE_CHECK_H
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
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:43:43 +02:00
#include "lib/del-stash.hpp"
(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 03:41:41 +02:00
#include "lib/nocopy.hpp"
#include <iostream>
#include <utility>
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
namespace lib {
namespace nifty { // implementation details
template<class X>
struct Holder
{
(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 03:41:41 +02:00
char payload_[sizeof(X)];
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
(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 03:41:41 +02:00
//NOTE: deliberately no ctor/dtor
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
(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 03:41:41 +02:00
X&
access()
{
return *reinterpret_cast<X*> (&payload_);
}
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
};
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:43:43 +02:00
template<class X>
uint Holder<X>::accessed_;
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
} // (End) nifty implementation details
/**
(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 03:41:41 +02:00
* A dependable data container available with extended lifespan.
* Automatically plants a ref-count to ensure the data stays alive
* until the last static reference goes out of scope.
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
*/
(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 03:41:41 +02:00
template<class X>
class DependableBase
: util::NonCopyable
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
{
(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 03:41:41 +02:00
static nifty::Holder<X> storage_;
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
(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 03:41:41 +02:00
public:
template<typename...ARGS>
explicit
DependableBase (ARGS&& ...args)
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
{
(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 03:41:41 +02:00
storage_.maybeInit (std::forward<ARGS> (args)...);
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
}
(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 03:41:41 +02:00
operator X& () const
{
return storage_.access();
}
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
uint use_count() { return nifty::Holder<PerClassMonitor>::accessed_; }
};
(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 03:41:41 +02:00
/** plant a static buffer to hold the payload X */
template<class X>
nifty::Holder<X> DependableBase<X>::storage_;
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
} // namespace lib
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:43:43 +02:00
#endif /*LIB_ZOMBIE_CHECK_H*/
Reference in a new issue Copy permalink